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ABSTRACT 

The  Canadian  Navy  hopes  to  achieve  significant  lifetime  cost  reductions  by 
implementing  optimized  crew  levels  across  its  next-generation  fleet.  Defence  Research  and 
Development  Canada  has  recognized  that  optimized  crewing  can  only  be  achieved  through  a 
thorough  Human-Systems  Integration  effort,  and  that  this  effort  will  require  systems  modelling 
techniques  to  help  the  Navy  predict  the  effectiveness  of  technologies  and  work  strategies  that 
aim  to  reduce  operator  workload  and  improve  mission  success.  This  report  describes  the  second 
phase  a  project  undertaken  to  provide  Defence  Research  and  Development  Canada  with  such  a 
technique,  and  details  the  development  of  two  damage  control  scenarios.  One  additional  phase  of 
analysis  is  planned,  to  identify  three  different  sets  of  damage  control  equipment  and  the  crew 
level  required  to  operate  that  equipment  under  the  damage  scenarios  that  have  been  defined.  The 
outputs  from  this  project  will  be  used  as  inputs  for  a  follow-on  project  to  develop  a  simulation  of 
human  and  automated  work  in  the  damage  control  domain.  The  scenarios  documented  in  this 
report  coupled  with  the  results  of  the  first  phase  of  work  are  a  strong  basis  for  the  final  phase  of 
this  project,  and  the  follow-on  simulation  development  effort. 
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La  Marine  canadienne  souhaite  reduire  de  facon  significative  les  couts  du  cycle  de  vie 
grace  a  roptimisation  des  equipages  de  sa  flotte  de  prochaine  generation.  Recherche  et 
developpement  pour  la  defense  Canada  a  reconnu  que  l'optimisation  de  rarmement  en  equipage 
ne  peut  se  realiser  que  par  l'integration  totale  des  systemes  humains  et  que  cela  exigera  des 
techniques  de  modelisation  de  systemes  qui  aideront  la  Marine  a  predire  l'efficacite  des 
technologies  et  des  strategies  de  travail  qui  ont  pour  but  de  reduire  la  charge  des  operateurs  et 
d’ameliorer  les  chances  de  succes  de  la  mission.  Ce  rapport  decrit  la  deuxieme  etape  d'un  projet 
qui  procurera  ces  moyens  a  Recherche  et  developpement  pour  la  defense  Canada  et  explique  les 
details  de  la  mise  au  point  de  deux  scenarios  de  controle  des  avaries.  Une  autre  etape  d'analyse 
est  prevue  :  elle  consiste  a  trouver  trois  equipements  de  controle  des  avaries  et  l’effectif 
necessaire  pour  faire  fonctionner  ses  equipements  compte  tenu  des  scenarios  de  controle  des 
avaries  definis.  Les  donnees  de  ce  projet  serviront  de  fondement  a  un  projet  de  suivi  visant  a 
simuler  le  travail  humain  et  automatise  dans  le  domaine  du  controle  des  avaries.  Les  scenarios 
documentes  dans  le  present  rapport,  conjugues  aux  resultats  de  le  premiere  etape  de  travail, 
constituent  un  solide  point  de  depart  pour  L etape  finale  de  ce  projet,  de  meme  que  pour  les 
travaux  subsequents  de  developpement  de  la  simulation. 
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In  response  to  its  recent  strategic  planning  activity,  the  Canadian  Navy  is  currently 
planning  for  a  significant  restructuring  of  their  forces.  Over  the  lifetime  of  a  class  of  ships, 
personnel  costs  are  much  larger  than  procurement  costs;  accordingly,  the  Navy  is  hoping  to 
develop  a  next-generation  fleet  that  includes  optimized  crewing  levels  to  reduce  personnel  costs. 
Defence  Research  and  Development  Canada  has  recognized  that  the  Navy’s  objectives  can  only 
be  met  through  a  thorough  Human  Systems  Integration  effort,  and  that  this  effort  will  require 
systems  modelling  techniques  that  will  help  the  Navy  to  predict  the  impact  of  various  crewing 
level  and  technology  combinations  on  operator  workload  and  mission  success. 

Defence  Research  and  Development  Canada  has  recently  initiated  a  project  to  provide 
the  Navy  with  a  systems  modelling  methodology  that  provides  a  workload  simulation  facility 
based  on  a  functional  model  of  the  system  of  the  interest.  It  is  hoped  that  this  methodology  will 
allow  for  comparisons  of  the  workload  induced  by  various  combinations  of  technology  and 
crewing.  Further,  since  it  is  expected  that  in  the  future  crewing  levels  will  be  predicated  on  the 
crew  requirements  for  damage  control,  damage  control  has  been  selected  as  the  domain  for  the 
development  of  this  new  analysis  suite. 

This  report  describes  the  results  of  the  second  phase  of  this  project,  in  which  one 
medium  and  one  high  complexity  damage  control  scenario  were  developed.  Included  in  the 
report  is  a  rationale  for  the  methodology  followed,  reviews  of  existing  damage  control  scenarios, 
reviews  of  real-world  damage  control  incidents,  details  on  the  two  scenarios  that  were 
developed,  a  task  inventory  to  describe  actor-independent  elements  of  work  that  must  be  carried 
out  for  each  scenario,  and  finally,  a  comprehensive  set  of  measures  of  effectiveness. 


iii 

©  2007  CMC  Electronics,  Inc. 


31  March  2007 


CMC  ELECTRONICS  INC. 

HUMAN  FACTORS  ENGINEERING 


SOMMAIRE 


DOC  NO 
1000-1370-2 


Dans  la  foulee  de  sa  recente  activite  de  planification  strategique,  la  Marine  canadienne 
planifie  actuellement  une  restructuration  importante  de  ses  effectifs.  Pendant  la  duree  de  vie 
d'une  classe  de  navires,  les  frais  en  personnel  s'averent  beaucoup  plus  eleves  que  les  frais 
d'acquisition  du  navire;  en  consequence,  la  Marine  souhaite  elaborer  une  flotte  de  la  prochaine 
generation  qui  optimise  l'armement  en  equipage  de  maniere  a  reduire  les  frais  en  personnel. 
Recherche  et  developpement  pour  la  defense  Canada  a  reconnu  que  les  objectifs  de  la  Marine  ne 
peuvent  etre  atteints  que  par  l'integration  totale  des  systemes  humains  et  que  cela  exigera  des 
techniques  de  modelisation  de  systemes  qui  aideront  la  Marine  a  predire  les  repercussions  de 
l’utilisation  de  differents  niveaux  d'effectifs  et  de  combinaisons  technologiques  sur  la  charge  de 
travail  des  operateurs  et  les  chances  de  succes  de  la  mission. 

Recherche  et  developpement  pour  la  defense  Canada  vient  de  lancer  un  projet  visant  a 
doter  la  Marine  d'une  methode  de  modelisation  de  systemes  permettant  de  simuler  la  charge  de 
travail  a  partir  d’un  modele  fonctionnel  du  systeme  auquel  on  s'interesse.  Cette  methode  devrait 
permettre  de  comparer  la  charge  de  travail  decoulant  de  differentes  combinaisons  de 
technologies  et  d'effectifs.  Par  ailleurs,  etant  donne  que  l'on  s'attend  a  ce  que  l'armement  en 
equipage  repose  a  l'avenir  sur  les  besoins  en  effectifs  charges  du  controle  des  avaries,  le  controle 
des  avaries  a  done  ete  retenu  comme  domaine  devant  servir  a  mettre  au  point  ce  nouveau 
programme  d'analyse. 

Ce  rapport  presente  les  resultats  de  la  deuxieme  etape  de  ce  projet  au  cours  de 
laquelle  deux  scenarios  de  controle  des  avaries  ont  ete  elabores.  L’un  de  ces  scenarios  presente 
une  situation  de  controle  des  avaries  de  complexity  moyenne  et  V autre  de  niveau  eleve.  Le 
present  rapport  contient  le  fondement  de  la  methodologie  utilisee,  des  etudes  des  scenarios 
actuels  de  controle  des  avaries,  des  etudes  de  comptes  rendus  d’ incidents  reels  impliquant  le 
controle  des  avaries,  des  details  sur  les  deux  scenarios  qui  ont  ete  mis  au  point,  un  inventaire  des 
taches  decrivant  certaines  particularites  qui  font  partie  de  chaque  scenario  (acteurs  ou  elements 
independants).  On  y  trouvera  egalement  un  ensemble  complet  de  mesures  d’ evaluation  du 
rendement. 
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SECTION  ONE  -  INTRODUCTION 


1.1  GENERAL 

In  response  to  its  recent  strategic  planning  activity  (2001),  the  Canadian  Navy  is 
currently  in  the  early  stages  of  planning  for  a  significant  restructuring  of  its  forces  (Canadian 
Department  of  National  Defence,  2005).  As  the  Navy’s  current  fleet  is  retired,  plans  are 
underway  to  replace  it  with  a  next  generation  fleet.  This  fleet  will  be  designed  to  meet  two 
objectives.  First,  the  Canadian  Navy  requires  increased  flexibility  to  allow  it  to  respond  to  a 
broader  range  of  threats  and  support  missions  that  are  expected  to  evolve  over  time.  Second,  the 
Navy  also  requires  a  fleet  that  will  be  more  cost  effective  than  the  current  fleet,  and  hopes  to 
achieve  this  through  reduced  manning  and  increased  commonality  of  equipment  and  training. 
Even  though  this  new  fleet  is  not  expected  to  be  operational  until  the  mid  2020’s,  the  long  lead 
times  involved  in  naval  procurement  (on  the  order  of  10  to  15  years  for  the  design  and 
acquisition  of  a  new  warship)  require  that  planning  must  begin  now. 

Defence  Research  and  Development  Canada  -  Toronto  (DRDC-T)  has  recognized 
the  important  role  that  human  performance  will  play  in  the  accomplishment  of  the  above 
objectives.  To  meet  its  objectives  of  expanding  capabilities  while  reducing  crew  size,  the  Navy 
must  find  a  way  to  amplify  the  capabilities  of  their  crews.  This  will  be  achieved,  in  part,  by 
equipping  the  fleet  with  new  and  advanced  forms  of  automation  that  will  permit  the  crew  to 
better  understand  evolving  situations  and  react  promptly  with  optimal  solutions.  However, 
automation  is  not  a  panacea,  and  poorly  conceived  automation  has  the  potential  to  actually 
increase  operator  workload  (Bost,  Mellis,  &  Dent,  1999)  and  make  the  joint  human-automation 
system  more  susceptible  to  failures  (Woods,  1996).  Notwithstanding  these  ‘ironies  of 
automation’  (Bainbridge,  1983;  Wiener,  1989),  automated  systems  have  tremendous  potential  for 
success  if  their  design  and  selection  is  based  on  a  thorough  human  factors  engineering  (HFE) 
analysis. 


In  response  to  the  Navy’s  strategic  plan  and  their  expected  increase  in  reliance  on 
automated  systems,  DRDC-T  is  seeking  to  develop  expertise  in  both  the  selection  of  automation 
technology  and  the  evaluation  of  human-machine  systems  that  leverage  automation.  In  terms  of 
selection,  they  are  seeking  to  develop  systems  modelling  techniques  that  will  help  to  generate 
guidance  criteria  for  the  selection  of  appropriate  automation.  In  terms  of  evaluation,  they  are 
seeking  to  develop  methods  of  workload  modelling  and  analysis  that  can  leverage  the  previous 
systems  modelling  effort  and  still  provide  valid  and  reliable  results  as  to  the  impact  of  different 
crewing  and  automation  options  on  human  workload. 

DRDC-T  has  identified  the  domain  of  damage  control  on  board  the  Halifax  class 
frigate  as  useful  for  the  development  of  their  expertise  in  these  areas.  While  the  damage  control 
systems  in  the  Halifax  class  frigate  are  not  scheduled  for  a  major  upgrade,  DRDC-T  expects  that 
any  insights  gained  from  an  analysis  of  damage  control  on  the  Halifax  class  frigate  will  readily 
generalize  to  the  proposed  successor  to  the  Halifax  class  frigate,  the  Single-Class  Surface 
Combatant  (SCSC).  Thus  the  domain  of  damage  control  on  the  Halifax  class  frigate  will  provide 
useful  insights  both  to  address  current  concerns  with  respect  to  methodology  development,  and 
also  to  provide  a  sound  basis  for  future  analyses  in  support  of  the  design  and  development  of  the 
SCSC. 
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1.2  PROJECT  OBJECTIVES 

The  main  objective  of  this  project  is  to  support  DRDC-T  in  the  development  of  a 
simulation  environment  that  will  enable  them  to  assess  the  performance  and  effectiveness  of  a 
given  level  of  crewing  and  automation  by  evaluating  the  impact  of  varying  levels  of  crew  and 
automation  on  damage  control  operations.  The  purpose  of  this  project  is  not  to  develop  the 
simulation  itself,  but  rather  to  perform  three  phases  of  analysis  to  prepare  for  that  work. 

a.  Phase  I:  Development  of  a  functional  model  of  damage  control.  The  first 
phase  of  this  work  was  intended  to  develop  a  means-ends  functional  model  of 
damage  control  that  is  not  based  on  specific  scenarios,  crewing  levels,  or 
automation  technologies.  Rather,  this  model  reflected  the  full  extent  of  Halifax 
class  frigate  damage  control  functions  in  a  manner  that  will  afford  later  ‘what-if 
analyses  to  be  conducted  based  on  different  scenarios,  crewing  levels,  and 
automation  technologies.  This  phase  of  the  project  was  completed  in  March  2006 
(see  Torenvliet,  Jamieson,  &  Coumoyer,  2006). 

b.  Phase  II:  Development  of  damage  control  scenarios.  The  functional  model 
developed  in  Phase  I  describes  the  work  domain  in  which  damage  control  is 
performed  on  the  Halifax  class  frigate.  The  objective  of  Phase  II  is  to  develop  two 
damage  scenarios,  one  of  medium  complexity  and  the  other  of  high  complexity. 

As  these  scenarios  will  be  used  to  test  different  crewing  and  automation  options,  it 
is  important  that  they  are  posed  in  a  way  that  will  generalize  to  all  three  options. 
Task  inventories  will  also  be  developed  for  each  of  the  scenarios  that  describe  the 
elements  of  work  that  could  be  assigned  to  either  a  human  actor  or  to  automation. 
Finally,  Measures  of  Effectiveness  (MOEs)  and  Measures  of  Performance 
(MOPs)  will  be  developed  that  allow  for  comparison  of  different  combinations  of 
crew  and  automation  in  the  network.  The  work  in  this  phase  will  be  an  important 
input  to  the  eventual  simulation  model  that  is  the  end-goal  of  the  larger  project. 
The  deliverables  from  this  phase  will  be  structured  for  portability  to  a  simulation 
effort.  The  work  from  this  phase  is  the  subject  of  this  report,  and  was  completed 
in  March  2007. 

c.  Phase  III:  Specification  of  crew-automation  options.  In  this  final  phase,  the 
work  of  the  first  two  phases  will  be  supplemented  by  the  identification  of 
possibilities  for  the  automation  of  damage  control,  the  specification  of  three 
options  for  damage  control  automation  (the  status  quo  option  that  characterizes 
the  automation  currently  in  use  in  the  Halifax  class  frigate;  an  intermediate  option 
that  uses  currently  available  and  tested  automation  technologies,  and  a  full  option 
that  employs  the  full  extent  of  the  state-of-the-art  in  automation  technologies), 
and  the  definition  of  the  crewing  levels  required  under  the  three  automation 
approaches.  As  with  Phase  II,  because  this  phase  will  produce  inputs  to  the  final 
simulation  model,  it  is  important  that  the  crew-automation  options  be  specified  in 
ways  that  are  readily  tractable  in  a  simulation  environment.  This  work  is  planned 
to  be  completed  in  June  2007. 

To  ensure  that  results  of  all  three  phases  accurately  represent  the  reality  of  damage 
control  operations  on  the  Halifax  class  frigate,  it  is  important  that  all  work  be  performed  in  close 
consultation  with  relevant  Subject  Matter  Experts  (SMEs).  This  will  ensure  that  the  work 
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products  accurately  capture  the  subtleties  of  the  damage  control  domain,  and  ultimately,  that  the 
final  simulation  model  will  be  valid  and  reliable. 

1.3  RATIONALE 

1.3.1  General 

While  the  first  phase  of  this  research  was  guided  by  an  established  methodology  for 
the  development  of  an  Abstraction  Hierarchy  (AH)  representation  of  a  work  domain,  this  second 
phase  of  scenario  development  was  not  predicated  on  any  established  methodology.  As  is 
discussed  below,  there  is  no  theoretically-based  formal  treatment  of  scenario  development  in  the 
Human  Factors  (HF)  literature.  In  the  absence  of  a  formal  methodology,  the  project  team  had  to 
conscientiously  define  a  suitable  approach  and  methodology  as  the  project  unfolded.  Our 
approach  was  based  on  three  considerations:  the  nature  of  the  scenarios  required  for  this  phase  of 
the  project,  the  complexity  of  understanding  how  the  damage  of  a  scenario  would  propagate 
through  the  Halifax  class  frigate,  and  the  specific  concerns  of  human  performance  with  advanced 
automation  that  these  scenarios  should  be  sensitive  to.  These  considerations  are  described  below. 

1.3.2  Scenarios  and  scenario  development 

While  scenarios  are  commonly  used  in  human-factors  design  (see,  e.g.,  Beyer  & 
Holtzblatt,  1998;  Courage  &  Baxter,  2005;  Go  &  Carroll,  2004;  Rosson  &  Carroll,  2002)  and  are 
the  starting  point  for  a  Human  Engineering  program  structured  according  to  MIL-HDBK- 
46855A  (United  States  Department  of  Defence,  1999),  there  is  little  agreement  in  the  HF 
literature  about  the  types  of  information  that  scenarios  should  include.  In  the  majority  of  cases, 
scenarios  are  stories  that  serve  to  add  depth  and  flavour  to  an  analysis  effort.  Rosson  &  Carroll 
(2002)  advocate  this  view:  “Scenarios  have  a  plot;  they  include  sequences  of  actions  and  events, 
things  that  actors  do,  things  that  happen  to  them,  changes  in  the  setting,  and  so  forth.  These 
actions  and  events  may  aid,  obstruct,  or  be  irrelevant  to  goal  achievement  (p.  18).” 

This  view  of  scenarios  is  actor-dependent,  but  scenarios  that  read  like  stories  may  not 
be  appropriate  for  this  project.  As  was  argued  in  the  report  on  the  first  phase  of  this  project,  since 
the  actual  damage  control  equipment  and  their  associated  crewing  levels  for  analysis  will  not  be 
defined  until  the  third  phase,  as  much  as  possible  the  work  prior  to  this  definition  should  be 
actor-independent  (Torenvliet  et  al.,  2006).  For  this  phase  of  the  project  to  produce  scenarios  that 
will  readily  generalize  from  the  current  equipment  in  the  Halifax  class  frigate  to  two  as-yet 
undefined  sets  of  damage  control  equipment  for  the  Halifax  class  frigate  and  their  associated 
crewing  levels,  it  would  be  helpful  if  the  scenarios  could  be  defined  without  reference  to  the 
damage  control  equipment  or  personnel  they  implicate.1 

If  a  scenario  is  defined  in  an  actor-independent  way  (that  is,  without  reference  to  the 
damage  control  automation  and  personnel  in  the  Halifax  class  frigate)  one  of  the  important 
variables  determining  how  the  scenario  will  play  out  over  time  -  the  actors  -  will  be  missing. 


1  While  it  would  be  beneficial  to  produce  this  sort  of  generalizable  scenario,  a  valid  alternative  approach  would  be  to 
produce  a  larger  set  of  fully  specified  scenarios  that  include  the  initial  damage  situation,  damage  control  equipment, 
and  crewing  level.  However,  in  the  long-run  this  approach  is  not  likely  to  be  as  efficient  as  using  more  generalizable 
scenarios.  Since  one  of  the  broader  aims  of  this  research  program  is  to  develop  a  technique  that  will  be  suitable  for 
other  contexts,  it  is  prudent  to  make  all  efforts  to  ensure  the  technique  is  as  efficient  as  possible. 
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Instead  of  being  a  story,  this  type  of  scenario  will  be  a  set  of  initial  conditions,  a  mise  en  scene. 
The  idea  of  treating  a  scenario  in  this  way  is  not  new.  Kirwan  (1987)  used  this  type  of  scenario 
twenty  years  ago  as  a  basis  for  a  human  reliability  analysis.  More  recently,  Kim  Vicente  and  his 
colleagues  have  performed  a  large  body  of  research  about  human  adaptation  in  a  process  control 
micro-world  that  treats  scenarios  as  a  set  of  initial  conditions  along  with  subsequent  faults.  These 
scenarios  serve  as  an  input  for  a  simulator  of  system  dynamics  (Vicente,  1997). 

While  the  literature  seems  to  reveal  an  inconsistent  treatment  of  scenarios  across 
different  authors  and  their  research,  there  is  a  less  apparent  consistency  at  work.  This  consistency 
is  not  at  the  level  of  the  scope  or  form  of  scenarios,  but  at  the  level  of  their  purpose.  In  all 
instances  where  scenarios  are  used,  from  full  stories  to  brief  mises  en  scene,  their  purpose  is  to 
specify  fixed  values  for  the  as-yet  unresolved  items  of  a  design  problem.  At  the  concept  stage, 
when  most  elements  of  the  system  are  unresolved,  story-based  scenarios  are  often  a  useful 
starting  point  for  design  and  analysis.  As  more  and  more  elements  of  the  design  are  resolved, 
scenarios  become  increasingly  constrained  because  the  established  elements  of  the  design  define 
the  way  in  which  the  system  will  respond  over  time.  Scenarios  are  still  useful  in  the  context  of 
systems  that  have  been  fully  designed,  but  in  this  case  they  can  only  address  the  way  in  which 
the  environment  impinges  on  the  system.  At  this  late  stage,  the  most  useful  scenario  is  a  mise  en 
scene  -  the  initial  conditions  and  any  perturbations  that  impinge  on  the  system  from  the 
environment.  But  in  all  cases,  the  purpose  of  a  scenario  remains  the  same  -  to  specify  fixed 
values  for  the  unresolved  items  of  a  design  problem. 

This  interpretation  of  scenarios  -  that  is,  that  they  should  specify  the  unresolved  items 
in  a  design  problem  -  defined  the  approach  to  scenario-building  followed  in  this  report.  Even 
though  these  scenarios  are  being  designed  to  support  conceptual  phase  analyses,  when  the 
scenarios  are  finally  used,  the  scope  of  the  unresolved  design  items  will  be  limited.  The  work 
already  performed  in  the  first  phase  of  the  project  defined  the  work  domain  within  which  damage 
control  operates.  This  work  domain  is  the  boundary  for  scenario  development  -  all  items  inside 
the  work  domain  are  potentially  resolvable  design  elements,  and  those  in  the  environment 
beyond  the  boundary  are  necessarily  unresolved.  Work  in  the  third  phase  will  define  three 
different  sets  of  damage  control  equipment  for  the  Halifax  class  frigate  and  the  crew  levels  they 
require  for  effective  operation.  Accordingly,  the  scenario  development  of  this  phase  should  result 
in  scenarios  that  specify  the  required  unknowns  outside  of  the  work  domain  /  environment 
boundary  established  in  the  first  phase  and  that  are  actor-independent  so  that  they  will  generalize 
to  the  three  equipment  and  crew  level  options  (design  elements  that  are  inside  the  work  domain  / 
environment  boundary)  of  the  third  phase.  In  other  words,  the  scenarios  to  be  developed  should 
be  in  the  form  of  mises  en  scene. 

1.3.3  Damage  propagation 

At  the  outset  of  this  phase,  the  project  team  expected  that  the  scenarios  to  be 
developed  would  include  two  types  of  information.  First,  they  would  begin  with  specific  damage 
control  incidents  (or,  ways  in  which  the  environment  impinges  on  the  work  domain).  Second, 
they  would  include  details  about  the  ways  in  which  the  damage  caused  by  the  incident  could 
potentially  propagate  across  the  ship  given  different  types  of  damage  control  interventions. 

As  the  work  for  this  phase  unfolded,  it  became  clear  that  these  two  types  of 
information  are  quite  different.  To  specify  damage  incidents,  it  is  necessary  to  understand  the 
complex  and  challenging  ways  in  which  the  environment  can  affect  the  ship.  It  was  clear  that  the 
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best  source  for  this  type  of  information  is  current  SMEs  in  naval  damage  control,  preferably  Sea 
Training  staff.  These  SMEs  are  experts  in  scenario-based  training  and  frequently  develop 
scenarios  that  are  intended  to  tax  even  experienced  damage  control  staff,  so  they  are  a  natural 
source  for  this  type  of  information. 

While  damage  control  SMEs  also  have  a  knowledge  of  the  way  in  which  damage 
propagates  across  the  ship,  their  level  of  understanding  is  tailored  to  the  objectives  of  containing 
and  resolving  damage  before  it  propagates  as  opposed  to  precisely  describing  the  way  in  which  it 
propagates.  In  other  words,  their  understanding  of  damage  propagation  is  based  on  the 
requirements  for  developing  and  executing  procedures  to  control  damage,  and  not  the  actual 
physics  describing  fire,  smoke,  and  flood  propagation.  For  example,  SMEs  have  heuristics  to 
predict  the  rate  at  which  a  fire  in  a  space  will  spread  if  no  measures  are  taken  to  contain  it  (6 
minutes  for  vertical  spread,  and  13  minutes  for  lateral  spread).  These  heuristics  work  because 
they  are  conservative  -  if  damage  control  efforts  are  coordinated  based  on  their  predictions, 
when  resources  are  available  to  set  a  fire  boundary,  it  will  be  planned  for  a  space  to  which  the 
fire  has  not  yet  spread.  However,  even  though  these  heuristics  are  effective  for  coordinating  a 
damage  control  response,  they  lack  accuracy.  The  spread  of  fire  is  not  simply  a  function  of  time, 
but  also  of  the  materials  in  the  space.  For  example,  a  fire  in  a  paint  locker  will  spread  at  a 
different  rate  than  a  fire  in  a  space  that  contains  only  a  trashcan  (indeed,  the  latter  fire  may  not 
have  enough  fuel  to  spread  at  all).  In  addition,  SMEs  do  not  have  heuristics  to  describe  how 
smoke  or  floods  spread.  In  terms  of  the  damage  control  response  required  for  these  types  of 
damage,  it  is  sufficient  only  to  understand  that  smoke  and  floods  do  spread,  and  quickly,  so 
boundaries  should  be  set  to  stem  their  spread  as  quickly  as  possible. 

The  level  of  understanding  of  the  physics  of  damage  propagation  held  by  SMEs  in 
damage  control  is  appropriate  for  and  well-suited  to  damage  control  operations.  It  also  helped 
SMEs  to  give  rich  descriptions  of  the  way  in  which  the  current  Halifax  class  frigate  crew  and 
damage  control  equipment  would  respond  to  damage.  It  is  not,  however,  the  best  basis  for  a 
study  of  the  workload  induced  by  various  different  types  of  damage  control  equipment  and  their 
associated  crewing  levels.  If  this  research  is  to  generate  strong  conclusions  related  to  optimized 
crewing,  it  would  be  better  served  by  a  model  of  damage  control  with  greater  detail  and  physical 
accuracy. 


The  formulae  required  to  accurately  describe  the  propagation  of  damage  are  complex, 
and  integrating  them  into  a  model  of  the  Halifax  class  frigate  in  a  way  that  would  generate  strong 
conclusions  on  human  workload  and  system  efficacy  would  be  costly  and  difficult.  Fortunately,  a 
great  deal  of  the  work  required  has  been  done  already  by  other  navies  around  the  world.  Most 
significantly,  the  US  Navy’s  Naval  Research  Lab  (NRL)  has  spent  over  10  years  and  US  $35 
million  building  a  series  of  increasingly  complex,  accurate,  and  efficient  models  of  damage 
propagation  (F.  Williams,  personal  communication,  27  February  2007).  This  work  has  focused 
on  building  predictive  models  of  the  propagation  of  smoke  and  fire,  and  has  resulted  in  the  Fire 
and  Smoke  Simulator  (FSSIM),  an  accurate  and  computationally  efficient  model  of  fire  and 
smoke  propagation  and  suppression  (Floyd,  Hunt,  Tatem,  &  Williams,  2004;  Floyd,  Hunt, 
Williams,  &  Tatem,  2004)  that  also  includes  a  graphical  user  interface  (Haupt  et  al.,  2006). 

While  FSSIM  is  not  currently  customized  for  the  Halifax  class  frigate,  it  is  able  to  generalize  to 
any  ship  as  defined  in  a  set  of  configuration  files.  FSSIM  does  not  include  treatment  of  flooding 
and  the  ship  stability  problems  that  flooding  induces,  but  this  problem  has  been  addressed  in 
another  NRL  simulation  program,  the  Illinois  Damage  Control  simulator  (Shou  et  al.,  2000; 
Sniezek,  Wilkins,  Wadlington,  &  Baumann,  2002;  Wilkins  &  Sniezek,  2000).  The  Illinois 
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Damage  Control  simulator  has  not  progressed  as  far  as  FSSIM,  but  its  solutions  to  flooding  and 
flood  control  are  well-documented  (see  the  Bibliography  included  in  Wilkins  &  Sniezek,  2000) 
and  could  potentially  be  integrated  with  FSSIM.  The  QinetiQ  corporation  has  also  developed  a 
similar  damage  control  simulator,  called  SURVIVE,  in  cooperation  with  the  United  Kingdom’s 
Ministry  of  Defence  (MOD)  (Turner,  Horstmann,  &  Bain,  2006). 

While  it  is  too  early  to  recommend  a  specific  simulator,  the  project  team  is  of  the 
opinion  that  this  research  project  would  be  better  served  by  adopting  one  of  these  simulators  of 
damage  propagation  than  by  attempting  to  build  a  new  one  from  scratch.  As  discussed  above, 
even  if  the  project  team  was  able  to  collect  more  detail  on  the  nature  of  damage  propagation  than 
heuristics,  a  simulation  based  on  those  insights  would  be  inaccurate  and  any  guidance  for 
optimized  crewing  based  on  that  simulation  would  be  weak.  On  the  other  hand,  if  the  final 
simulator  is  based  on  an  accurate  and  validated  model  of  damage  propagation,  it  would  be  able 
to  produce  stronger,  more  defensible  guidance  for  optimized  crewing.  Consequently,  the 
scenarios  presented  in  this  report  only  include  the  ways  in  which  the  environment  could  impinge 
on  the  Halifax  class  frigate  to  cause  damage,  and  do  not  include  details  of  damage  propagation 
beyond  a  high-level  presentation  of  the  extent  of  damage  that  could  be  caused  by  each  scenario. 

1.3.4  Human  performance  with  advanced  automation 

A  major  aim  of  this  research  is  to  ensure  that  automation  employed  in  future  damage 
control  systems  capitalizes  on  human  capabilities  and  respects  human  limitations.  It  is  therefore 
important  that  the  scenarios  developed  in  this  phase  be  sensitive  to  known  human-automation 
interaction  issues.  Over  the  past  two  decades,  a  growing  literature  has  drawn  attention  to  the 
potential  drawbacks  of  human  automation  interaction.  Lee  (2006)  provides  a  structure  for 
considering  how  these  drawbacks  might  be  manifested  in  damage  control  automation. 

1.3.4. 1  Out-of-the-loop  unfamiliarity 

Control  engineers  often  think  about  automation  in  the  context  of  feedback  control 
loops.  In  that  context,  automation  replaces  control  loops  that  include  a  human  element  with  ones 
that  do  not.  The  effect  of  this  is  either  to  remove  the  human  from  the  control  model  altogether,  or 
more  frequently  to  assign  the  human  to  supervisory  control  loops  -  away  from  the  data,  decision, 
and  doing  frontier.  Once  outside  the  inner  control  loops,  human  operators  find  it  very  difficult  to 
remain  in  tune  with  what  the  automation  is  doing.  Several  aspects  of  automation  design 
contribute  to  this  problem.  First,  automation  systems  frequently  fail  to  provide  the  human 
supervisor  with  adequate  feedback  (that  is,  information)  about  the  behaviour  of  inner  control 
loops.  Second,  the  human  operator  is  not  well-suited  to  the  passive  monitoring  task,  even  when 
provided  with  adequate  feedback.  Third,  supervisory  control  encourages  task  switching  and 
interruptions  which  further  remove  the  operator  from  the  inner  control  loops.  Finally,  since 
operators  are  out-of-the-loop,  they  tend  to  develop  poor  mental  models  of  inner  control  loops  and 
the  processes  that  they  control. 

All  four  of  these  design  factors  are  likely  to  contribute  to  human-automation 
challenges  in  damage  control.-  The  first  aspect,  removal  of  the  human  from  inner  control  loops, 


2  It  is  important  to  note  that  the  assertions  to  follow  are  necessarily  predictive  -  the  damage  control  automation  does 
not  yet  exist.  It  would  be  deceptively  easy  for  any  automation  designer  to  dismiss  these  predictions.  Engineers  are, 
in  fact,  adept  problem  solvers  and,  once  made  aware  of  any  specific  issue,  can  posit  viable  solutions  to  them  The  key 
here  is  that  the  predictions  are  a  projection  of  persistent  observations  of  difficulties  encountered  when  humans 
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is  likely  a  necessary  design  decision  if  reduced  workload  (or  reduced  manning)  is  to  be  achieved. 
The  design  challenge  is  to  provide  access  to  inner  control  loops  without  overloading  the  operator 
-  a  very  difficult  balance  to  strike.  The  second  and  third  aspects  remind  us  that  the  operator  is 
likely  to  have  an  incomplete  awareness  of  the  automation  state  and  behaviour.  The  final  aspect  of 
automation  design  that  contributes  to  out-of-the-loop  unfamiliarity,  poor  mental  models,  can  be 
viewed  as  a  consequence  of  the  above  and  a  precursor  to  inappropriate  reliance  decisions  (see 
Section  1.3. 4.4,  below). 

1.3.4.2  Clumsy  automation 

Automation  is  frequently  targeted  at  high-tempo  phases  of  work  with  the  aim  of 
reducing  operator  workload  (see  Section  1.3. 4.1,  above).  Ironically,  if  the  human-automation 
interaction  is  not  well  anticipated,  this  can  result  in  an  increase  in  workload  at  times  when  the 
human  is  already  busy.  This  phenomenon  is  called  ‘clumsy  automation’;  clumsy  automation  can 
be  further  subdivided  into  non-routine  or  routine  clumsiness.  Non-routine  clumsiness  is 
associated  with  non-routine  events  in  the  domain.  This  could  include  maintenance  evolutions  or 
emergency  operations.  Routine  clumsiness  is  manifested  during  routinely  occurring  high 
workload  phases  of  operations,  such  as  start-up  or  shutdown  of  major  systems.  For  example, 
flight  management  systems  are  notorious  for  forcing  pilots  to  perform  data  entry  tasks  during 
busy  pre-flight  evolutions. 

Damage  control  seems  highly  susceptible  to  non-routine  clumsy  automation.  The 
highly  temporal  nature  of  the  domain  suggests  that  the  most  critical  automation  tasks  will  be 
performed  when  the  operator  is  extremely  busy  and  under  extraordinary  duress.  What  might  be 
anticipated  as  necessary  and  simple  human  inputs  to  the  automation  could  quickly  become 
overwhelming  annoyances. 

Damage  control  automation  may  also  be  susceptible  to  routine  clumsiness,  but  to  a 
much  lesser  extent  compared  to  non-routine  clumsiness.  In  the  damage  control  domain,  set-up 
may  be  necessary  when  a  ship  makes  ready  to  sail  or  when  maintenance  activities  cause 
temporary  changes  in  the  resources  or  constraints  of  the  damage  control  system. 

1.3.4.3  Automation-induced  errors 

Even  well-design  automation  introduces  new  opportunities  for  humans  to  make 
errors,  and  the  occurrence  of  those  errors  and  their  effects  can  be  difficult  to  predict  or  detect. 
There  are  three  types  of  errors  that  are  commonly  acknowledged  to  be  induced  by  automation: 

a.  Mode  errors.  Mode  errors  occur  when  mode  status  or  transitions  are  not 
effectively  communicated  to  operators.  Operator  actions  that  are  reasonable  in 
one  mode  may  have  dramatically  different  effects  in  another  mode. 

b.  Brittle  failures.  Brittle  failures  occur  when  simple  data  entry  slips  result  in 
sudden  and  severe  degradation  in  system  performance.  Opportunities  for  such 
failures  are  afforded  by  highly  automated  decision  processes  that  are  susceptible 
to  poor  quality  data. 


interact  with  advanced  automation.  It  is  the  aim  of  this  research  to  circumvent  these  design  shortcomings  through 
informed  analysis  and  design. 
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c.  Configuration  errors.  Configuration  errors  occur  in  the  set-up  phase  of 
automation,  particularly  if  data  entries  are  not  rigorously  checked. 

Of  these  three  types  of  errors,  mode  errors  are  the  most  insidious  and  the  most  widely 
discussed  in  the  human  factors  literature.  Designers  use  modes  to  increase  the  context  sensitivity 
of  the  automation.  Although  the  approach  is  powerful  and  flexible,  human  operators  engaged  in 
supervisory  control  experience  a  great  deal  of  difficulty  keeping  in  sync  with  the  automation 
modes,  particularly  when  those  modes  are  poorly  enunciated  or  when  transitions  are  induced  by 
internal  logic  that  is  not  well  understood  by  the  human. 

Brittle  failures  and  configuration  errors,  while  important,  appear  to  be  more 
idiosyncratic.  Both  can  be  thwarted  by  rigorous  input  checking  -  an  accepted  practice  in 
software  engineering.  It  is  not  expected  that  these  types  of  errors  will  be  a  large  factor  in  the 
context  of  the  present  study. 

1.3.4.4  Inappropriate  trust 

Trust  is  a  complex  attitude  held  by  a  person  towards  other  agents  (including 
automated  ones)  that  may  help  or  hinder  achievement  of  the  person’s  goals.  Because  this  attitude 
develops  implicitly  and  in  response  to  a  wide  variety  of  influences,  it  is  extremely  difficult  to 
model.  However,  there  is  substantial  empirical  evidence  that  trust  affects  reliance  on  automation. 
Inappropriate  reliance  behaviour  can  take  the  form  of  misuse  (relying  on  automation  that  is 
incapable)  or  disuse  (rejecting  capable  automation).  Since  people  tend  to  rely  on  trusted 
automation  and  reject  distrusted  automation,  it  is  easy  to  anticipate  how  trust  plays  a  substantial 
role  in  reliance  decisions  and  the  appropriateness  of  those  decisions. 

1.3.4.5  Behavioural  adaptation 

Operators  and  organizations  often  adapt  their  behaviours  in  ways  that  nullify  the 
safety  or  performance  advantages  of  automation.  This  adaptation  is  usually  implicit  and  may  take 
one  of  two  forms.  First,  operators  sometimes  respond  to  increases  in  safety  with  more  risky 
behaviour;  as  if  a  risk  set-point  exists  for  the  system  as  a  whole.  Second,  organizations  may 
suffer  a  ‘diffusion  of  responsibility’  amongst  themselves.  This  can  create  situations  in  which  no 
one  is  explicitly  responsible  for  critiquing  the  decisions  and  actions  of  the  automation. 

These  types  of  behavioural  adaptation  are  not  expected  to  be  a  major  issue  for 
damage  control  automation.  The  maladaptive  behaviour  of  adopting  more  risky  behaviour  is 
most  commonly  encountered  in  familiar  tasks  that  are  aided  by  automation.  For  example,  anti¬ 
lock  braking  systems  do  not  improve  driving  safety  because  drivers  adapt  by  traveling  at  higher 
speeds  and  braking  more  aggressively.  Damage  control  automation  is  unlikely  to  replace  tasks 
that  are  so  highly  practiced,  so  this  maladaptive  behaviour  seems  unlikely.  Diffusion  of 
responsibility  also  seems  an  unlikely  problem  for  damage  control  automation  because  military 
organizations  are  highly  practiced  at  role  allocation  and  reinforcement.  One  would  expect  this 
organizational  strength  to  carry  over  to  mixed  initiative  damage  control  teams. 

1.3.4.6  Skill  loss  and  skill  shift 

Workers  often  suffer  degradation  in  their  manual  task  performance  skills  when  those 
skills  are  not  regularly  practiced  (as  is  the  case  when  the  skill-based  tasks  are  automated).  These 
tasks  are  often  associated  with  physical  control  tasks,  but  degradation  of  cognitive  tasks  have 
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also  been  noted.  In  situations  where  automation  assumes  only  a  portion  of  the  tasks  associated 
with  a  job,  it  may  have  the  effect  of  shifting  emphasis  to  other  skills.  If  these  skills  are  less 
robust  in  the  operator  population,  the  joint  human-automation  system  may  suffer  performance 
degradations  from  the  introduction  of  automation. 

1.3.4.7  Job  satisfaction 

Although  automation  is  often  envisaged  by  designers  as  relieving  workers  of  some 
burden,  it  often  has  the  unintended  effect  of  reducing  worker  satisfaction  with  their  job.  This  is 
often  explained  as  a  combined  reduction  in  decision  latitude  and  increase  in  work  demands. 
While  automation  may  reduce  workload,  it  also  reduces  an  operator’s  ability  to  affect  the  work 
system,  resulting  in  a  reduced  sense  of  control.  Meanwhile,  the  operator  remains  in  charge  of  a 
more  powerful  and  capable  system;  one  that  requires  him  to  exercise  less  robust  skills  at  a  pace 
determined  by  a  machine.  The  result  can  be  highly  demoralizing  for  the  worker. 

1.3.4.8  Implications 

The  implications  of  this  review  of  human  performance  with  advanced  automation  for 
this  project  are  summarized  in  Table  1-1,  below.  While  this  review  has  identified  a  large  number 
of  issues  that  have  important  implications  for  this  project,  Table  1-1  shows  that  these 
implications  will  require  more  active  consideration  in  Phase  III  of  this  project  (when  automated 
solutions  are  being  considered)  and  during  the  development  of  the  simulation  of  damage  control 
(when  the  workload  associated  with  the  use  of  automation  are  being  considered,  and  sensitivity 
conditions  around  the  use  of  automation  are  being  developed). 

Even  though  these  considerations  are  expected  to  be  most  important  during  Phase  III, 
this  work  was  also  grounded  in  them  as  they  were  reviewed  a  number  of  times  during  the 
development  of  the  scenarios,  task  inventories,  and  MOPs/MOEs  detailed  in  this  report. 

Table  1-1.  Summary  of  the  implications  of  known  issues  in  human  performance  with  advanced 
automation  for  this  project. 


Issue 

Implications 

Priority 

Out-of-the-loop 

unfamiliarity 

If  possible,  the  simulation  should  include  sensitivity  tests  in 
which  the  human  working  with  the  automation  makes  a  poor 
decision  based  on  a  lack  of  familiarity  with  the  inner 
workings  of  the  automation.  (Note  that  this  may  be 
challenging  to  do  in  a  convincing  way.) 

Moderate 

Clumsy 

automation 

Analysis  of  the  candidate  automated  systems  should  focus 
on  identifying  the  tasks  that  the  operator  must  engage  in 
only  to  manage  the  automation,  and  should  identify  the 
phases  of  operation  in  which  the  automation  requires 
operator  input.  This  information  will  be  an  important  input  to 
determining  the  human  workload  induced  by  the  automation. 

High;  this  is  an 
important 
consideration  for 
damage  control. 
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Issue 

Implications 

Priority 

Automation- 
induced  errors 

Analysis  of  the  candidate  automated  systems  should  focus 
on  identifying  their  various  modes  of  operation  and  the 
criteria  for  auto-switching  between  modes.  This  should  help 
to  reveal  the  potential  for  mode  errors,  the  effects  of  which 
can  be  added  as  sensitivity  tests  in  which  the  human 
working  with  the  automation  makes  an  action  that  would  be 
appropriate  for  one  mode,  but  that  is  not  appropriate  in  the 
current  mode. 

High;  this  is  an 
important 
consideration  for 
damage  control. 

Inappropriate 

trust 

Sensitivity  testing  for  simulations  of  the  automated  systems 
should  include  instances  when  the  automation  is  not  trusted 
(and  so  the  operator  relies  on  other  methods  to  gather 
information,  make  conclusions,  or  effect  actions)  and  is 
over-trusted  (and  so  the  operator  relies  on  the  conclusions 
and  recommendations  of  the  automation  even  when  they 
are  wrong). 

High;  this  is  an 
important 
consideration  for 
damage  control. 

Behavioural 

adaptation 

This  is  not  likely  to  be  a  significant  issue  in  a  military 
context. 

Low 

Skill  loss  and 
skill  shift 

This  is  not  likely  to  be  a  significant  issue  in  the  context  of 
this  project. 

Low 

Job  satisfaction 

Since  damage  control  is  only  a  small  aspect  of  shipboard 
work,  and  one  that  -  if  its  effectiveness  is  enhanced  -  will 
increase  the  safety  of  the  crew,  job  satisfaction  is  not  likely 
to  be  a  significant  issue. 

Low 

1.4  PURPOSE  OF  THIS  REPORT 

This  report  provides  an  account  of  the  work  performed  for  the  second  phase  of  the 
larger  project  described  in  Section  1.2,  above. 

1.5  REPORT  OUTLINE 


This  report  consists  of  the 

;  following  sections; 

a. 

Section  One  - 

Introduction 

b. 

Section  Two  - 

Methodology 

c. 

Section  Three  - 

Results 

d. 

Section  Four  - 

Discussion,  Conclusions,  and  Recommendations 

e. 

Section  Five  - 

References 

f. 

Annex  A 

Glossary  of  Terms  and  Acronyms 

g- 

Annex  B 

Agenda  for  SME  Data  Collection  Meeting 
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SECTION  TWO  -  METHODOLOGY 


2.1  GENERAL 

This  section  details  the  methodology  followed  to  develop  the  medium  and  high 
complexity  damage  control  scenarios,  the  task  inventory,  and  MOEs  and  MOPs. 

2.2  REVIEW  OF  OBJECTIVES 

Since  the  work  described  in  this  report  is  a  part  of  a  larger  research  project,  part  of 
which  has  already  been  completed  (Torenvliet  et  al.,  2006),  and  part  of  which  has  not  yet  been 
fully  defined  (see  Section  1.2),  the  project  team  began  this  phase  of  the  work  by  reviewing  the 
objectives  of  this  larger  research  project  and  the  specific  objectives  for  this  phase. 

2.3  SCENARIO  REVIEW 

The  first  step  in  developing  a  set  of  damage  control  scenarios  was  to  acquire  and 
review  a  comprehensive  set  of  existing  damage  control  scenarios.  Three  different  types  of 
scenarios  were  reviewed: 

a.  Damage  control  training  scenarios.  Training  scenarios  are  those  used  to  train 
CF  personnel,  and  have  been  developed  by  the  CFNES  for  training  conducted  at 
the  Damage  Control  Training  Facility  (DCTF)  or  by  Sea  Training  for  training 
conducted  on  ships,  either  during  ship  Workups  (WUPS)  or  while  at  sea.  The 
project  team  was  able  to  acquire  a  set  of  80  DCTF  scenarios  (each  packaged  as  a 
Microsoft  Word  file)  and  16  Sea  Training  scenarios  with  evaluations  for  3 
different  crews  on  each  scenario  (packaged  as  3  Microsoft  Excel  files,  each  with 
information  on  the  16  scenarios  as  applied  to  a  single  ship).  These  scenarios  were 
reviewed  to  understand  their  basic  form,  elements  that  might  be  candidates  for  re¬ 
use,  and  domain-specific  language  that  should  be  considered  in  the  development 
of  the  scenarios  for  this  project. 

b.  Actual  naval  damage  control  incidents.  Over  the  past  few  years,  there  have 
been  a  number  of  high-profile  naval  damage  control  incidents  involving  craft 
similar  to  the  Halifax  class  frigate.  The  project  team  identified  the  following 
incidents  to  review:  (1)  The  HMS  Nottingham,  which  in  2002  ran  aground  off  the 
coast  of  Australia;  (2)  The  USS  Cole,  which  in  2000  was  the  subject  of  a  terrorist 
bombing;  (3)  The  USS  Princeton,  which  in  1991  was  damaged  by  an  Iraqi  sea- 
mine;  (4)  The  USS  Samuel  B.  Roberts,  which  in  1988  was  damaged  by  an  Iranian 
sea-mine;  and  (5)  The  USS  Stark,  which  in  1987  was  hit  by  two  Iraqi  Exocet 
missiles.  These  incidents  were  chosen  due  to  their  recency  (all  have  occurred  in 
the  past  20  years)  but  they  also  include  a  wide  range  of  damage  control  concerns. 
They  were  reviewed  to  understand  the  ways  in  which  documented  damage  control 
incidents  differ  from  (or  are  similar  to)  training  scenarios,  and  to  gain  familiarity 
with  the  complexities  of  these  incidents.  The  reviews  were  brief,  focusing  on 
materials  readily  available  on  the  internet,  as  opposed  to  in-depth  forensic 
reviews. 
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c.  Scenarios  for  testing  advanced  automation.  The  US  Navy’s  Naval  Research 
Laboratory  has  been  exploring  the  application  of  advanced  automation  to  damage 
control  in  the  Damage  Control  Automation  for  Reducing  Manning  (DC-ARM) 
project  (Williams  et  al.,  2003).  The  five  different  peacetime  scenarios  and  one 
comprehensive  wartime  scenario  that  were  composed  for  the  DC-ARM  project 
were  reviewed. 

In  addition,  since  the  scenarios  developed  in  this  research  will  ultimately  be  used  to 
investigate  the  efficacy  of  advanced  automation  in  reducing  the  size  of  the  damage  control  team 
required  for  operational  effectiveness,  the  project  team  also  hoped  to  be  able  to  review  vendor 
scenarios  designed  specifically  for  testing  advanced  automation.  Inquiries  were  made  about  such 
scenarios  with  one  large  vendor  of  damage  control  automation,  L-3  MAPPS,  but  this  vendor 
does  not  currently  have  scenarios  specifically  for  this  purpose.  Instead  of  focusing  on  the  human 
performance  concerns  of  automation,  this  vendor’s  human  factors  test  strategy  has  a  much 
broader,  system-oriented  focus  (R.  St-Pierre,  personal  communication,  13  February  2007).  While 
it  is  unfortunate  that  the  project  team  was  not  able  to  locate  vendor  scenarios  for  testing 
automation,  the  DC-ARM  scenarios  helped  to  provide  some  insight  into  the  way  automation 
should  be  tested,  and  the  human  performance  concerns  related  to  automation  have  also  been  an 
important  consideration  throughout  this  research  (see,  for  example,  Section  1.3.4). 

2.4  SCENARIO  DEVELOPMENT 

2.4.1  SME  data  collection  meeting 

After  a  basic  understanding  of  damage  scenarios  was  gained  through  the  scenario 
review,  the  work  of  developing  the  medium  and  high  complexity  scenarios  commenced.  This 
work  began  with  a  trip  to  Sea  Training  Atlantic  at  Canadian  Forces  Base  (CFB)  Halifax.  There, 
the  project  team  held  a  one-day  scenario  development  data  collection  meeting.  The  following  CF 
personnel  were  in  attendance: 

a.  LCdr  Andrew  Bellas,  the  Sea  Training  Atlantic  MSE  Officer; 

b.  LCdr  Chris  Howlett,  the  Sea  Training  Atlantic  CSE  Officer;  and 

c.  LCdr  Roger  Heimpel,  CFNES  Damage  Control  Division  Commander. 

The  following  project  team  personnel  were  also  in  attendance: 

a.  Dr.  Renee  Chow,  the  project  SA; 

b.  Commander  (Cdr)  (Retired)  Michael  Churcher,  who  has  experience  in  MSE  on  a 
number  of  CF  platforms. 

c.  Mr.  Gerard  Torenvliet,  the  project  lead. 

The  purpose  of  this  meeting  was  to  develop  preliminary  outlines  for  one  medium  and 
one  high  complexity  damage  scenario.  As  can  be  seen  from  the  meeting  agenda  (included  in 
Annex  B),  this  was  accomplished  in  a  meeting  with  five  distinct  parts: 

a.  Common  ground  /  project  overview.  The  purpose  of  the  first  part  of  the  meeting 
was  to  discuss  the  project  objectives  in  general  and  the  requirements  for  the 
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scenarios  in  particular.  This  included  a  discussion  of  scenario  complexity  and 
scenario  scope,  as  well  as  a  discussion  of  what  would  be  the  eventual  MOEs  and 
MOPs  for  the  damage  control  effort  performed  in  response  to  these  scenarios.  The 
discussion  of  scenario  scope  focused  on  defining  the  stopping  rules  for  the 
scenarios,  that  is,  criteria  defining  when  damage  can  be  considered  as  solved,  or 
out  of  control. 

b.  Scenario  identification.  The  purpose  of  the  second  part  of  the  meeting  was  to 
identify  the  medium  and  high  complexity  incidents  from  which  to  develop  the 
damage  scenarios.  Staff  members  from  both  Sea  Training  and  DCTF  were 
present,  and  they  were  encouraged  to  work  from  the  scenarios  they  were  familiar 
with  to  generate  these  initial  ideas.  The  discussion  of  scenario  complexity  that 
took  place  in  the  first  part  of  the  meeting  was  frequently  referenced  to  ensure  that 
the  scenarios  chosen  would  involve  qualitatively  different  amounts  of  damage. 

c.  Scenario  development  -  medium  complexity  scenario.  The  next  step  was  to 
take  the  idea  for  the  medium  complexity  scenario  and  to  work  out  in  detail  the 
way  the  damage  from  that  scenario  would  evolve  on  the  Halifax  class  frigate.  A 
timeline  was  established  and  then  details  were  fleshed  out  along  that  timeline. 

d.  Scenario  development  -  high  complexity  scenario.  After  participants  completed 
a  first  pass  on  the  medium  complexity  scenario,  the  high  complexity  scenario  was 
worked  out  in  detail  in  the  same  way,  along  with  its  timeline. 

e.  Scenario  refinement.  During  the  last  portion  of  the  meeting,  we  revisited  both 
the  medium  and  high  complexity  scenarios  to  fill  in  any  missing  information,  and 
also  to  develop  a  number  of  preliminary  measures  of  effectiveness  and  measures 
of  performance. 

An  attempt  was  also  made  to  gather  data  about  the  generic  properties  of  damage 
spread  from  the  CF  personnel  present  at  the  meeting;  it  was  hoped  that  this  data  would  help  in 
developing  rules  for  predicting  the  spread  of  damage  across  the  Halifax  class  frigate. 
Unfortunately,  SMEs’  rules  for  predicting  damage  spread  (see  Section  1.3.3),  while  effective  at 
ensuring  that  damage  control  resources  are  deployed  in  the  right  locations,  do  not  generalize  well 
outside  of  the  current  procedures  for  controlling  damage  in  the  Halifax  class  frigate.  As  is 
detailed  in  Section  1.3.3,  on  the  basis  of  this  finding  the  overall  approach  to  this  project  was 
changed  to  rely  on  more  accurate  predictions  of  damage  spread  available  through  damage  control 
simulators  such  as  FFSIM,  Illinois,  or  SURVIVE. 

2.4.2  Scenario  development 

The  data  collected  during  the  SME  data  collection  meeting  was  then  refined  into 
preliminary  versions  of  the  medium  and  high  complexity  scenarios.  The  first  step  in  this  process 
was  to  write  a  set  of  notes  from  the  SME  data  collection  meeting  and  then  to  refine  those  notes  in 
a  series  of  project  team  meetings  to  ensure  that  they  included  all  of  the  data  from  the  SME 
meeting.  As  a  part  of  this  refinement,  we  paid  particular  attention  to  the  criteria  for  scenario 
complexity  and  stopping  rules  that  were  established  with  input  from  SMEs. 

The  records  from  the  data  collection  meeting  showed  a  strong  focus  on  the 
procedures  currently  in  use  in  the  Halifax  class  frigate.  While  these  procedure -based  notes  have 
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been  kept  for  reference  in  the  next  phase  of  this  project,  to  make  the  scenarios  actor-independent 
it  was  necessary  to  abstract  them  away  from  procedure-based  descriptions  to  some  actor- 
independent  core.  Consequently,  instead  of  developing  the  scenarios  as  a  full  time  evolution 
based  on  current  Halifax  class  frigate  procedures,  it  was  decided  to  develop  them  instead  as  a  set 
of  initial  conditions  along  with  high-level  predictions  on  the  way  damage  would  propagate  if 
there  were  no  damage  control  response.  In  this  framework,  each  scenario  has  three  important 
phases: 


a.  Initial  damage.  This  phase  describes  the  parts  of  the  ship  affected  by  the  initial 
onset  of  damage.  For  fires,  this  was  typically  the  specific  space  in  the  ship  where 
ignition  occurred;  for  floods,  this  was  the  source  of  the  flood  (either  the  location 
of  a  hull  rupture  or  a  fire-main  break);  and  finally,  for  structural  integrity 
problems,  this  was  the  location  of  the  bulkhead,  deck,  or  wall  breach. 

b.  Primary  propagation.  This  phase  describes  the  parts  of  the  ship  that  would  be 
affected  by  the  first-level  propagation  of  damage.  For  fires,  propagation  was  from 
the  initial  damage  to  the  entire  zone  or,  for  zone  fires,  to  adjacent  zones.  For 
floods,  the  initial  (and  only)  propagation  was  flooding  to  the  waterline  of  affected 
spaces,  or  flooding  as  per  hatch  configurations  for  fire-main  ruptures.  Propagation 
of  structural  damage  was  not  anticipated  because  ships  are  typically  very  well- 
built  and  structural  damage  does  not  propagate  (see  the  results  of  the  review  of 
actual  damage  control  incidents  in  Section  3.2.3)  and,  if  structural  damage  were  to 
propagate,  the  project  team  did  not  have  the  knowledge  to  predict  the  conditions 
under  which  and  the  ways  in  which  it  would  propagate. 

c.  Secondary  propagation.  Under  this  framework,  fires  are  the  only  type  of  damage 
to  have  a  secondary  propagation,  and  this  propagation  is  from  all  affected  zones  to 
all  adjacent  zones  (up,  down,  fore,  and  aft). 

Since  the  results  of  the  SME  data  collection  meeting  indicated  that  any  capable 
damage  control  system  must  stop  damage  prior  to  its  tertiary  propagation,  damage  propagation 
was  not  modelled  beyond  secondary  propagation. 

The  scenarios  were  recorded  in  two  ways.  First,  a  chart  was  prepared  for  each 
scenario  that  included  the  initial  conditions  (e.g.,  “Peacetime  cruising,  Damage  Condition  Y”),  a 
brief  framing  story,  and  a  hierarchy  showing  the  initial  damage  and  primary  and  secondary  levels 
of  propagation.  Second,  the  initial  damage  points  and  the  primary  and  secondary  levels  of 
propagation  were  illustrated  on  a  diagram  of  the  Halifax  class  frigate. 

2.4.3  SME  review 

Initial  versions  of  the  scenarios  were  distributed  to  a  Sea  Training  SME,  CPO  Gary 
White.  A  teleconference  was  held  with  CPO  Gary  White  (Sea  Training  Atlantic  Marine 
Electrical  Engineering)  on  20  February  2007  where  they  were  reviewed.  All  comments  from  this 
review  were  integrated  into  the  final  version  of  the  scenarios,  which  are  presented  in  Sections 

3.3.4  and  3.3.5. 
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2.5  TASK  INVENTORIES 

After  the  scenarios  were  complete,  the  project  team  developed  a  task  inventory  that 
catalogued  the  minimum,  but  sufficient  number  of  task  types  that  are  required  to  cope  with  each 
damage  scenario.  As  with  much  of  the  work  already  completed  for  this  project,  the  tasks  in  the 
task  inventory  were  specified  in  an  actor-independent  way  so  they  will  generalize  to  the  third 
phase  of  this  project  (where  specific  sets  of  damage  control  equipment  and  their  associated 
crewing  levels  will  be  defined)  and  the  eventual  simulation  that  is  to  be  developed  as  a  result  of 
this  project.  To  do  this,  the  project  team  used  the  first  steps  of  a  Hierarchical  Task  Analysis 
(Annett,  2003,  2004),  a  functional,  actor-independent  form  of  task  analysis,  to  develop  the  task 
inventories. 

Although  the  project  team  originally  intended  to  develop  two  task  inventories,  one 
corresponding  to  each  scenario,  the  degree  of  overlap  between  the  two  inventories  was  so 
substantial  that  they  were  merged  into  a  single  inventory.  In  the  final  analysis,  there  were  no 
tasks  that  we  could  rule  out  for  either  scenario  because,  in  an  actor-independent  context,  it  is 
impossible  to  know  how  far  or  in  what  ways  the  damage  would  propagate  over  time.  In  addition, 
the  project  team  also  hoped  to  be  able  explicitly  to  map  each  task  back  to  the  AH  of  damage 
control.  While  each  task  was  assessed  to  ensure  that  it  fell  within  the  bounds  of  the  AH,  the 
original  proposal  to  perform  this  mapping  was  naive.  Even  high-level,  actor-independent  tasks 
can  be  driven  by  concerns  of  multiple  nodes  at  multiple  levels  within  an  AH,  and  similarly,  can 
affect  multiple  nodes  at  multiple  levels  within  the  AH.  As  it  turned  out,  the  process  of  ensuring 
that  all  of  the  concerns  of  each  task  could  be  accounted  for  within  the  existing  AH  uncovered 
one  issue  that  had  not  been  considered  before. 

The  results  of  this  analysis  are  documented  in  Section  3.4. 

2.6  MEASURES  OF  EFFECTIVENESS  AND  MEASURE  OF  PERFORMANCE 

2.6.1  Background 

A  brief  search  of  the  literature  reveals  that  there  are  many  different  definitions  of  the 
terms  MOE  and  MOP.  These  terms  are  used  widely,  and  often  casually.  For  this  project, 
however,  it  is  important  to  make  a  clear  distinction  between  MOEs  and  MOPs,  because  they  are 
subtly  but  importantly  different  from  one  another. 

The  most  precise  definition  that  the  project  team  could  find  of  MOEs  was  the 

following: 


Measures  of  effectiveness:  Metrics  used  to  measure  results  achieved  in  the 
overall  mission  and  execution  of  assigned  tasks.  (Chairman  of  the  Joint 
Chiefs  of  Staff,  2003,  pp.  GL-9,  emphasis  added) 

In  a  slightly  different  context,  the  US  Department  of  Defence’s  Modelling  & 
Simulation  Glossary  defines  MOPs  as  follows: 

Measure  of  Performance.  Measure  of  how  the  system/individual  performs 
its  functions  in  a  given  environment  (e.g.,  number  of  targets  detected, 
reaction  time,  number  of  targets  nominated,  susceptibility  of  deception,  task 
completion  time).  It  is  closely  related  to  inherent  parameters  (physical  and 
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Department  of  Defence,  1998,  p.  136,  emphasis  added) 

The  emphasized  words  in  each  definition  show  the  clear  distinction  between  MOEs 
and  MOPs:  MOEs  measure  results  achieved  while  MOPs  measure  attributes  of  system 
behaviour.  For  example,  in  the  context  of  damage  control,  an  MOE  might  be  the  amount  of  fire 
spread,  and  the  criterion  for  effectiveness  might  be  that  the  fire  may  not  spread  beyond  the  zone 
where  it  started.  An  MOP  related  to  this  MOE  could  be  the  time  required  to  set  a  boundary 
around  a  fire,  and  the  criterion  for  performance  might  be  that  boundaries  must  be  set  above  in  six 
minutes,  and  fore  and  aft  in  13  minutes. 

This  distinction  relates  back  to  the  theme  of  actor-independence  already  introduced  in 
this  report.  Whereas  MOEs  should  be  defined  already  in  early  stages  of  system  design,  to  help 
set  criteria  on  what  the  system  must  be  able  to  achieve,  MOPs  can  only  be  defined  in  later  stages 
of  design  when  the  specific  equipment,  actors,  and  processes  put  in  place  to  achieve  the  MOEs 
are  being  established.  At  this  stage,  MOPs  measure  items  related  to  the  achievement  of  the 
MOEs  that  are  specific  to  the  equipment,  actors,  and  processes  that  have  been  specified.  Still, 
even  when  the  MOPs  have  been  defined,  the  MOEs  remain  to  define  the  sine  qua  non  of  the 
system. 
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Since  MOPs  cannot  be  defined  until  the  equipment,  actors,  and  processes  required  to 
meet  the  MOEs  have  been  established,  it  is  currently  too  early  to  define  MOPs;  this  must  wait 
until  the  next  phase  of  the  project.  At  present  the  three  different  sets  of  damage  control 
equipment,  actors,  and  processes  have  not  yet  been  defined,  so  this  is  an  appropriate  time  to 
define  MOEs.  As  will  be  seen,  the  AH  of  damage  control  is  a  useful  basis  for  doing  this.  (It 
should  be  noted,  however,  that  once  the  equipment,  actors,  and  processes  for  damage  control 
have  been  defined  that  it  may  become  clear  that  some  MOEs  would  be  better  considered  as 
MOPs.) 

2.6.2  Method 

The  method  followed  to  establish  MOEs  was  to  consider  each  of  the  nodes  of  the  AH 
model  of  damage  control,  to  determine  if  there  are  any  quantitative  measures  for  the  constraints 
of  each  node  that  can  be  considered  as  MOEs.  This  was  done  bottom  up,  beginning  at  the 
Physical  Function  level  of  the  model  and  proceeding  up  to  the  Functional  Purpose  level.  The 
bottom  up  strategy  was  chosen  because  it  was  deemed  likely  that  nodes  at  higher  levels  of  the 
model  might  have  MOEs  that  are  aggregations  of  those  for  nodes  at  lower  levels.  In  addition, 
since  the  task  inventory  includes  many  items  that  can  easily  be  used  to  define  MOEs,  items  from 
the  task  inventory  were  used  as  the  basis  for  MOEs  as  much  as  was  possible. 

Specific  nodes  at  the  Physical  Form  level  (that  is,  specific  compartments  or  tanks) 
were  not  explicitly  considered  in  this  work.  It  is  likely  that  in  an  actual  design  effort,  specific 
instantiations  of  the  MOEs  would  be  put  in  place  for  specific  compartments  (e.g.,  fires  in 
magazines  must  be  extinguished  before  munitions  in  the  magazine  explode;  fires  in  the 
Operations  Room  must  be  extinguished  in  less  than  three  minutes,  etc.),  but  it  is  expected  that 
these  compartment-specific  MOEs  will  be  tailored  versions  of  more  general  MOEs 
corresponding  to  nodes  in  higher  levels  of  the  AH. 

The  MOEs  that  were  developed  are  documented  in  Section  3.5. 
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3.1  GENERAL 

This  section  presents  the  four  major  results  for  Phase  II  of  this  project  -  a  review  of 
damage  control  scenarios  and  incidents  (Section  3.2),  the  development  of  two  scenarios  of 
damage  control  (Section  3.3),  the  development  of  task  inventories  related  to  each  scenario 
(Section  3.4),  and  the  development  of  measures  of  effectiveness  and  performance  (Section  3.5). 

3.2  SCENARIO  REVIEW 

3.2.1  General 

This  section  of  the  report  details  the  results  of  the  scenario  review  described  in 
Section  2.3. 

3.2.2  Review  of  damage  control  training  scenarios 

As  discussed  in  Section  2.3,  the  project  team  reviewed  a  set  of  80  DCTF  damage 
control  scenarios,  and  16  Sea  Training  Scenarios.  This  section  describes  the  results  of  this 
review. 

3.2.2. 1  DCTF  scenarios 

The  DCTF  at  the  CFNES  is  intended  to  teach  ship’s  crews  the  skills  and  procedures 

of  damage  control  in  a  realistic  environment.  It  provides  initial  and  refresher  training  to  all 
Halifax  class  frigate  crews,  as  well  as  team  training  to  crew  members  assigned  to  any  of  the 
damage  control  section  bases.  The  heart  of  the  DCTF  is  a  network  of  typical  ship  compartments 
surrounded  by  a  damage  control  training  infrastructure.  Each  compartment  includes  special 
equipment  to  allow  instructors  to  create  and  control  fires,  smoke,  and  floods.  The  DCTF  allows 
for  the  relatively  realistic  emulations  of  fires  and  floods  in  a  safe,  controlled,  and  stable 
environment.  While  this  has  many  benefits  for  training,  the  experience  is  still  not  the  same  as 
real  battle  damage.  DCTF  trainees  can  learn  to  expect  the  ways  in  which  damage  can  manifest 
itself  in  each  compartment,  and  because  damage  is  controlled  by  instructors,  the  experience  can 
feel  safe  and  predictable.  To  increase  the  reality  and  psychological  pressure  of  DCTF  training 
exercises,  training  is  typically  based  on  damage  scenarios.  These  scenarios  are  each  a  specific 
mise  en  scene,  and  include  a  framing  story  to  situate  trainees,  the  times  at  which  instructors 
should  initiate  the  various  types  of  damage  the  DCTF  can  emulate,  and  the  ways  in  which 
damage  can  spread  if  trainees  are  not  properly  following  the  normative  procedures.  The 
scenarios  also  include  miscellaneous  directions  for  the  instructors,  and  some  include  specific 
instructional  aims.  The  scenarios  do  not,  however,  include  specific  MOEs  (as  can  be  found  in  the 
Sea  Training  scenarios;  see  Section  3. 2. 2. 2,  below).  It  is  likely  that  MOEs  are  communicated  to 
instructors  by  some  other  method. 

The  typical  contents  of  a  DCTF  scenario  are  as  follows: 

a.  Aim  (optional).  Some  of  the  scenarios  begin  with  a  brief  statement  of 
instructional  aims  (e.g.,  “to  re-affirm  the  abilities  of  the  attack  team”). 
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b.  Scenario.  The  main  opening  feature  of  all  scenarios  is  a  statement  of  the  incident 
driving  the  scenario  (e.g.,  “The  threat  is  Multi.  Two  attacks,  1  each  from  both  the 
Port  and  Stbd.  Sides.  One  missile  from  each  attack.  DCTF  engages  and  splashes 
both.  However,  fragments  from  the  downed  missiles  cause’s  fires  /  a  Firemain 
break  /  various  equipment  failures  and  casualties  throughout  the  ship.  Ship's  Helo 
is  air  borne.fi.  Some  scenarios  also  include  details  of  the  ship’s  damage  control 
state  (e.g.,  “ Peacetime  cruisingfi. 

c.  Sequence  of  events.  The  broad  story  driving  the  scenario  is  always  followed  by  a 
statement  of  the  precise  timing  of  the  incidents  that  make  up  each  scenario. 
Typically,  the  timing  begins  at  -6  minutes  so  that  the  crew’s  ability  to  ‘close  up’ 

.  .  .  *  T 

to  action  stations  by  a  scenario  time  of  0  minutes  can  be  tested.  Damage 
incidents  can  arise  any  time  after  scenario  time  -6.  These  incidents  are  described 
with  a  scenario  time,  story-based  details  to  explain  the  damage,  specific 
instructions  for  DCTF  to  emulate  that  damage,  and  details  of  the  broader  impact 
of  the  damage  and  the  ways  to  emulate  that  (e.g.,  “ SPLASHED  MISSILE  IMPACT 
# 2  -  PORTSIDE.  Causing  major  fires  on  the  PORTSIDE  of  Sections  IF  and 
Major  flood  in  section  2E.  Fragment  damage  causes  a  Firemain  BREAK  at 
Frame  42,  1  Deck.  Fire  Pump  #  2  is  rendered  unavailable  and  is  lost.  **NOTE: 
Isolation  of  the  Firemain  break  at  frame  42,  should  cause  a  complete  failure  of 
the  Firemain  aft  of frame  40.  This  will  affect  any  fire  attack  teams  aft.  There  must 
be  co-ordination  between  the  Engine  Rm.  Staff,  Control  Rm.  and  the  Passageway 
staff.fi  The  sequence  of  events  also  includes  the  way  in  which  damage  will  spread 
if  crews  are  not  responding  appropriately  (e.g.,  “ T+10 :  Fire  spread  to  SMI-E 
and/or  1  Mess  if  poor  response  to  ships  office  and  with  no  boundary  established 
fivdofblkd32.fi. 

d.  Explanatory  notes.  Many  scenarios  also  include  a  set  of  explanatory  notes  that 
can  include  additional  details  on  how  to  emulate  the  damage  (e.g.,  “ On  initiate 
primary  fires  start,  Low,  Door  open  is  Key  for  High  Fire  where  required.fi,  how 
the  training  should  be  monitored  (e.g.,  “ For  each  fire  incident,  the  standard  lead 
instructor  and  safety  numbers  will  be  employed.fi,  any  specific  procedural 
benchmarks  that  must  be  respected  (e.g.,  “ Fleet  standard  for  boundaries  is 

T+ 10.fi,  and  other  assorted  training  directives  (e.g.,  “ Free  play  will  be  tolerated. 
Timings  are  to  be  strictly  adhered  to.fi. 

e.  Monitoring  positions  and  incident  coordinators.  All  scenarios  also  include 
these  sections,  which  give  guidance  for  how  the  DCTF  staff  should  be  deployed 
throughout  the  facility  during  the  scenario. 

f.  Additional  details.  Scenarios  close  with  an  extended  discussion  of  each  of  the 
events  in  the  scenario.  These  discussions  include  more  specific  information  about 
the  way  in  which  damage  should  be  emulated  within  a  compartment,  the  correct 
procedural  responses  for  trainees  to  demonstrate,  the  correct  fire  boundaries  to 
set,  and  the  criteria  (if  any)  for  declaring  trainees  who  do  not  perform  the  proper 


3  In  damage  control  terms,  ‘closing  up’  is  the  process  by  which  the  ship  transitions  from  any  state  to  a  state  where 
the  various  damage  control  stations  are  manned  and  all  personnel  assigned  to  damage  control  are  either  responding 
to  damage  or  are  able  to  do  so. 
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damage  control  responses  or  precautions  as  casualties  (e.g.,  “The  Fwd  Engine 
Room  is  “ LOST  TO  SEA  ”  in  the  second  attack.  Any  Boundary  that  is  established 
in  the  Fwd.  ER  will  be  a  casualty  as  a  result”  or  “ Power  isolation  to  the  space 
must  be  considered  before  anyone  steps  into  the  water.  Make  casualty  of  first 
person  who  steps  into  the  water  if  power  is  not  isolated.”). 

g.  Signs.  Finally,  some  scenarios  close  with  a  number  of  signs  printed  in  large  text. 
These  signs  (e.g.,  “GUN  POWER  SUPPLY  DAMAGED  BEYOND  REPAIR ”)  can 
be  printed  out  and  posted  around  the  DCTF  to  give  trainees  information  about 
scenario  items  that  cannot  be  emulated  by  DCTF  equipment. 

The  structure  presented  above  was  used  consistently  across  all  of  the  80  DCTF 
scenarios  analyzed.  In  addition  to  following  this  structure,  there  were  many  scenarios  that  were 
exact  duplicates  of  one  other.  Even  for  scenarios  that  have  different  initiating  incidents  and 
timing,  they  all  tended  to  make  use  of  similar  types  of  damage.  This  is  because  the  DCTF  only 
has  a  limited  number  of  compartments,  each  of  which  are  designed  to  emulate  specific  types  of 
damage.  For  example,  many  of  the  scenarios  include  fires  in  the  mess  and  galley,  floods  in  the 
after  engine  room,  and  a  requirement  for  a  casualty  power  run  from  frame  40  to  20. 

While  DCTF  staff  are  able  to  use  different  scenario  stories  in  conjunction  with  a 
relatively  small  number  of  possible  types  of  damage  (when  compared  with  an  entire  ship)  to 
create  challenging  training  exercises,  those  scenarios  have  limited  value  for  the  definition  of 
scenarios  for  this  project.  In  the  context  of  this  project,  their  main  value  was  to  help  the  project 
team  to  understand  the  flavour  of  a  typical  damage  control  scenario.  Since  DCTF  scenarios  are 
so  specific  to  the  compartments  of  the  DCTF,  the  project  team  did  not  anticipate  to  be  able  to  re¬ 
use  any  of  the  elements  of  these  scenarios.  Finally,  in  its  review  of  these  scenarios,  the  project 
team  did  not  identify  any  domain-specific  language  or  terminology  that  it  was  not  already 
familiar  with. 

3.2.2. 2  Review  of  Sea  Training  scenarios 

The  two  Sea  Training  organizations  of  the  Canadian  Navy,  Sea  Training  Atlantic  and 
Sea  Training  Pacific,  have  as  their  primary  function  to  conduct  operational  training.  As  a  part  of 
this  primary  function,  they  create  training  materials  and  evaluate  operational  capabilities  in 
preparation  for  employing  ships  in  a  variety  of  tasks.  The  strength  of  Sea  Training  when 
compared  to  the  DCTF  is  that  they  can  train  using  the  whole  ship;  the  obvious  weakness  is  that 
training  on  the  ship  can  involve  only  lightly  simulated  damage.  Consequently,  the  training 
delivered  by  Sea  Training  cannot  add  the  same  realism  to  teaching  the  skills  of  damage  control 
as  the  DCTF,  but  can  be  stronger  than  the  DCTF  in  terms  of  training  in  procedures,  ship 
navigation,  and  crew  coordination. 

Even  though  their  environments  are  different,  there  are  many  similarities  between 
DCTF  and  Sea  Training  scenarios:  both  include  a  listing  of  damage  incidents  over  time,  as  well 
as  details  for  how  training  staff  should  deploy  to  support  the  conduct  and  evaluation  of  the 
scenario.  There  are  two  significant  differences.  First,  although  Sea  Training  scenarios  may  be 
labelled  with  an  indication  of  a  framing  story  (e.g.,  “ Bomb  Threat  # 3  -  The  Big  Boom”),  quite 
often  a  framing  story  is  missing.  Many  scenarios  only  have  functional  labels,  like  “DC  Problem 
#7”.  Second,  the  scenarios  also  include  specific  directions  as  to  how  performance  should  be 
evaluated.  Framing  details  are  not  included  because  Sea  Training  scenarios  are  typically  used 


3.3 

©  2007  CMC  Electronics,  Inc. 


31  March  2007 


CMC  ELECTRONICS  INC. 

HUMAN  FACTORS  ENGINEERING 


DOC  NO 
1000-1370-2 


during  ship  WUPS,  when  the  ship  is  already  operating  within  a  larger  scenario.  Sea  Training 
scenarios  complement  the  broader  ship  scenario  and  so  they  do  not  require  framing  details  of 
their  own. 


Sea  training  scenarios  follow  a  more  rigid  template  than  DCTF  scenarios.  The  typical 
contents  of  a  Sea  Training  scenario  are  as  follows: 

a.  Header  -  origin,  date,  ship  class  and/or  name,  type  of  training,  and  title. 

Every  scenario  includes  a  standard  header  to  communicate  the  origin  of  the 
scenario  (Sea  Training  Atlantic  or  Pacific),  the  date  the  scenario  was  run,  the  class 
of  ship  it  was  designed  for,  the  type  of  training  (e.g.,  “WUPS”),  and  the  title  (e.g., 
the  descriptive  “ Bomb  Threat  # 3  -  The  Big  Boom ”  or  the  functional  “ DC  Problem 
#7”).  These  headers  are  more  formal  than  those  for  the  DCTF  scenarios, 
presumably  because  Sea  Training  scenarios  and  the  evaluation  become  a  part  of 
the  ship’s  record. 

b.  Scenario.  Just  as  with  DCTF  scenarios,  the  main  opening  feature  of  Sea  Training 
scenarios  is  a  statement  of  the  scenario.  For  Sea  Training  scenarios,  however,  the 
incident  is  described  at  the  granular  level  of  individual  damage  points;  these 
points  are  generally  not  tied  together  by  a  framing  story.  For  example,  “T  —  Bomb 
explodes  -NBCD  filtration  #2.  Major  fires  NBDC  Filt  #2,  Switchboard  # 1 , 
WardRoom.  Firemain  rupture  FS  24.  T+10  —  Fire  AC  Plant  #2  if  no  boundary 
set.” 

c.  Detailed  scenario  breakdown.  The  remaining  portions  of  a  Sea  Training 
scenario  present  the  scenario  in  detail.  The  main  features  here  are  a  breakdown  of 
the  Sea  Training  staff  assigned  to  monitor  the  various  ship  staff,  details  of  how 
the  damage  for  the  individual  damage  incidents  is  to  be  simulated,  and  criteria 
about  how  simulated  damage  should  spread.  These  scenarios  can  also  include 
CSE  considerations,  such  as  specifications  of  the  equipment  that  is  lost  as  a  result 
of  damage,  and  details  of  the  casualties  that  will  be  sustained  at  various  points 
during  the  scenario. 

d.  Scenario  critique.  Sea  Training  scenarios  also  include  a  critique  of  the 
performance  of  a  ship’s  crew  in  addressing  the  scenario.  This  critique  begins  by 
commenting  on  the  performance  of  the  ship’s  crew  in  following  the  appropriate 
damage  control  procedures,  with  a  focus  on  the  performance  of  the  damage 
discoverer,  the  attack  teams,  and  the  damage  boundaries.  Each  of  these  parties  is 
given  a  rating  of  satisfactory  or  unsatisfactory,  which  is  then  rolled  up  into  a 
satisfactory  /  unsatisfactory  rating  for  the  overall  incident.  The  evaluation  is 
rounded  out  with  a  focus  on  each  of  the  groups  contributing  to  the  damage  control 
effort:  Command,  Damage  Control  Headquarters  (HQ1),  Ops,  Forward  Section 
Base  (FSB),  Aft  Section  Base  (ASB),  Section  Base  3  (SB3),  the  manning  pool, 
the  Emergency  Response  Team  (ERT),  and  Casualty  Clearing.  The  time  required 
for  each  of  these  groups  to  close  up  is  measured,  comments  are  made  on  their 
overall  performance,  and  they  are  given  a  satisfactory  /  unsatisfactory  rating.  The 
critique  closes  out  with  a  set  of  general  comments  and  an  overall  satisfactory  / 
unsatisfactory  rating.  Overall,  these  critiques  are  a  good  indication  of  the  most 
useful  MOPs  for  training  damage  control. 
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The  structure  described  above  was  used  in  all  of  the  scenarios.  Despite  the  strict 
format,  the  Sea  Training  scenarios  exhibited  a  much  greater  range  of  damage  locations  than  the 
DCTF  scenarios,  indicative  of  the  fact  that  the  scenario  authors  had  a  larger  canvas  for  scenario 
design  available  to  them  (the  whole  ship). 

The  value  of  the  Sea  Training  scenarios  in  terms  of  this  project  is  that  they  help  to 
emphasize  the  wide  range  of  damage  that  can  happen  to  a  ship.  They  also  help  to  clarify  that  in 
terms  of  the  current  Halifax  class  frigate  damage  control  system,  which  largely  requires  manual 
fire-fighting,  there  are  two  ways  to  add  complexity  to  a  scenario  -  increasing  the  number  of 
damage  incidents  and  decreasing  the  amount  of  resources  available  for  damage  control. 
Additionally,  in  the  context  of  a  manned  response,  additional  complexity  can  be  added  if  damage 
is  in  spaces  that  are  difficult  to  access,  either  because  the  entry  is  down  a  ladder  (directly  into  the 
path  of  the  heat  coming  from  the  fire)  or  because  the  most  efficient  advance  path  has  been 
blocked.  Since  these  scenarios  seem  to  have  been  designed  with  the  aim  of  varying  levels  of 
complexity,  the  general  form  of  these  scenarios  informed  the  discussions  that  were  conducted 
with  SMEs  to  establish  the  two  scenarios  for  this  project. 

3.2.3  Review  of  actual  naval  damage  control  incidents 

While  the  review  of  damage  control  training  scenarios  helped  the  project  team  to 
understand  the  ways  in  which  typical  damage  control  scenarios  can  be  constructed,  damage 
control  training  scenarios  only  represent  the  types  of  damage  that  SMEs  can  readily  anticipate. 
While  these  types  of  damage  control  problems  do  occur  while  ships  are  at  sea  (for  instance,  one 
SME  told  us  of  a  fire  he  experienced  early  in  his  career  that  started  in  a  trash  can  containing 
some  oily  rags),  the  complex  damage  control  problems  that  occur  in  practice  are  often  much 
more  complex  than  even  the  most  difficult  Sea  Training  scenarios.  To  get  a  broader  view  of  the 
types  of  damage  possible,  five  prominent  damage  control  incidents  were  reviewed  to  better 
understand  the  complexities  of  real-life  damage  control  work. 

3.2.3. 1  HMS  Nottingham  -  Major  flooding  incident 

On  7  July  2002,  the  HMS  Nottingham,  a  UK  Type  42  destroyer,  ran  aground  on  a 
submerged,  but  well-charted  rock  200  miles  off  the  coast  of  Australia.  The  collision  with  the 
rock  ripped  a  50m  long  gash  in  the  hull  of  the  ship,  from  the  bow  to  the  bridge,  which  induced 
major  flooding  in  five  separate  compartments  (including  the  large  Forward  Engine  Room), 
nearly  causing  the  ship  to  sink.  Damage  control  efforts  were  able  to  save  the  ship,  but  not 
without  help  from  external  agencies.  Once  the  crew  of  the  ship  had  the  flooding  under  control, 
members  of  the  New  Zealand  navy  came  aboard  to  continue  the  effort.  In  the  end,  the  ship  was 
saved  only  because  the  crew  performed  a  major  shoring  effort  to  reinforce  the  bow  and  plug 
some  of  the  hull  breaches.  Even  with  this  effort,  the  ship  could  not  be  sailed  back  to  the  UK  on 
its  own,  but  was  instead  sea-lifted  on  a  semi-submersible  heavy-lift  ship. 
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Figure  3-1.  The  damaged  HMS  Nottingham  being  sea-lifted  back  to  the  UK. 

The  project  team  was  not  able  to  find  a  great  deal  of  detail  on  this  incident  in  the 
public  domain.  Nonetheless,  the  details  that  are  available  demonstrate  some  important 
characteristics  of  a  major  flood-related  damage  control  incident.  First,  it  is  very  difficult  to  sink  a 
modem  warship.  The  Nottingham  had  a  large  gash  along  one  third  of  its  length,  and  yet  survived. 
Second,  for  a  flood  to  be  a  major  damage  control  incident  on  its  own,  it  has  to  be  very  large. 
Third,  flooding  incidents  have  long  time  constants.  Fires  can  spread  quickly  and  so  introduce  a 
great  deal  of  time  pressure  into  an  incident,  but  flooding  generally  spreads  much  more  slowly. 
When  a  damage  control  organization  is  confronted  with  floods  and  fires,  floods  can  typically  be 
ignored  until  the  fires  have  been  contained. 

Sources:  Wikipedia.org 

(http://en.wikipedia.org/wiki/HMS_Nottingham_%28D91%29);  PSi  Daily  Shipping  News  for  14 
July  2002 

(http://www.ibiblio.Org/maritime/Scheepvaartnieuws/Pdf/scheepvaartnieuws/2002/juli/0 1 3-15- 
07-2002.PDF).  Sources  were  last  accessed  on  28  Febmary  2007. 

3.23.2  USS  Cole 

On  12  October  2000,  while  refuelling  in  Yemen,  the  USS  Cole  was  hit  by  a  large 
explosive  device  brought  alongside  the  ship  on  a  small  boat.  The  resulting  explosion  blasted  a 
35-foot  diameter  hole  in  the  side  of  the  ship,  killed  17  sailors  and  injured  39  others,  and  caused 
major  flooding  in  the  ship’s  engineering  spaces  and  major  fires  in  the  ship’s  galley.  Although 
few  details  can  be  found  on  the  damage  control  effort,  the  damage  on  the  Cole  seems  to  have 
been  difficult  to  contain.  Casualty  clearing  confused  the  initial  response  to  the  fires  induced  by 
the  explosion,  and  due  to  the  size  of  the  hole  in  the  ship,  flooding  was  a  major  long-term 
concern.  The  attack  occurred  at  midday,  and  damage  is  reported  to  have  been  under  control  by 
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evening.  Just  as  with  the  HMS  Nottingham,  the  USS  Cole  was  crippled  and  had  to  be  sea-lifted 
home  on  a  heavy-lift  ship. 


Figure  3-2.  A  close-up  of  the  damage  inflicted  on  the  USS  Cole.  For  scale  purposes,  note  the  size  of  the 

sailors  in  the  foreground. 

Again,  the  project  team  was  not  able  to  find  many  details  on  the  damage  control 
response  to  the  damage  inflicted  on  the  USS  Cole.  The  details  that  are  available,  however, 
demonstrate  especially  that  casualties  can  add  significant  confusion  to  a  damage  control  effort.  In 
addition,  in  instances  where  casualty  clearing  is  required,  the  casualties  can  also  imply  resource 
shortages  that  will  affect  a  ship’s  ability  to  combat  damage  quickly.  Even  though  the  US  Navy 
has  surely  learned  many  important  damage  control  lessons  from  the  USS  Cole,  this  incident 
again  demonstrates  that  modern  warcraft  are  very  resilient  to  damage  -  even  a  35  ft  diameter 
hole  was  not  able  to  sink  the  USS  Cole. 

Sources:  Wikipedia.org  (http://en.wikipedia.org/wiki/USS_Cole_bombing);  Surface 
Warfare  Magazine  (http://www.dcfp.navy.mil/mc/museum/COLE/Colel.htm);  NavSource 
Online  (http://www.navsource.org/archives/05/01067.htm);  DoD  USS  Cole  Commission  Report 
(http://www.defenselink.mil/pubs/cole20010109.html).  Sources  were  last  accessed  on  28 
February  2007. 


3.7 

©  2007  CMC  Electronics,  Inc. 


31  March  2007 


CMC  ELECTRONICS  INC. 

HUMAN  FACTORS  ENGINEERING 


DOC  NO 
1000-1370-2 


3.23.3  USS  Princeton 

On  18  February  1991,  the  USS  Princeton  was  operating  in  a  known  mine-field  in  the 
Persian  Gulf  when  it  struck  a  large  acoustic  mine.  The  initial  explosion  lifted  the  fantail  of  the 
ship  nearly  out  of  the  water,  and  the  subsequent  shock  waves  (worsened  by  the  sympathetic 
detonation  of  another  mine  300  yards  away)  heaved  the  ship  with  horizontal  and  vertical 
deflections  of  four  to  six  feet  on  a  cycle  of  six  to  seven  seconds.  Although  the  mine  did  not  blast 
a  hole  in  the  hull,  the  structural  damage  from  the  shock  waves  was  severe:  forty  feet  from  the 
stern,  8  inch  by  10  inch  I-beams  snapped;  the  fantail  was  nearly  severed  from  the  ship;  a  six-inch 
crack  opened  on  the  ship’s  superstructure,  and  more  than  ten  percent  of  the  superstructure  was 
separated  from  the  deck;  there  was  also  major  hull  buckling  over  the  length  of  the  ship;  and 
finally,  there  were  many  instances  of  flooding  through  various  fractures,  burst  welds,  and  split 
seals.  At  the  time  of  the  explosion,  the  Princeton  was  also  turning  hard  to  starboard.  The  blast 
jammed  the  port  rudder  in  its  position,  so  the  ship  could  not  be  steered.  In  terms  of  the  AH 
presented  in  the  first  phase  of  this  project,  the  three  main  functional  purposes  of  the  ship  were 
severely  compromised: 

a.  Stability.  It  is  estimated  that  80%  of  the  ship’s  structural  integrity  had  been 
compromised,  and  90  minutes  after  the  incident,  the  ship’s  captain  was  still  trying 
to  figure  out  if  the  ship  was  going  to  sink. 

b.  Manoeuvrability.  The  ship  was  in  the  middle  of  hostile  waters,  but  was  not  able 
steer.  Due  to  the  structural  damage  it  had  sustained,  the  vibrations  from  running 
the  gas  turbines  could  have  sunk  the  ship. 

c.  Mission  effectiveness.  The  ship’s  weapons  systems  were  incapacitated,  and  basic 
defences  were  not  restored  for  105  minutes. 

Remarkably,  even  though  most  of  the  crew  were  hurled  off  of  their  feet  by  the  force 
of  the  blast,  no  crewmembers  were  killed  in  this  incident  and  only  three  were  injured. 


3.8 

©  2007  CMC  Electronics,  Inc. 


31  March  2007 


CMC  ELECTRONICS  INC. 

HUMAN  FACTORS  ENGINEERING 


DOC  NO 
1000-1370-2 


Figure  3-3.  One  of  the  cracks  in  the  USS  Princeton’s  hull  as  a  result  of  the  mine  it  hit. 

The  case  of  the  USS  Princeton  demonstrates  that  the  constraints  in  the  ship’s  work 
domain  are  very  important  considerations  in  a  damage  control  incident.  Published  reports  show 
the  captain  actively  considering  how  close  the  ship  was  to  sinking,  how  much  structural  integrity 
remained  in  the  hull,  how  to  get  moving  as  quickly  as  possible,  and  how  to  restore  the  ship’s 
ability  to  fight.  It  also  demonstrates  that  a  ship  can  have  a  very  major  damage  event  without 
experiencing  a  single  fire.  Finally,  it  again  demonstrates  that  there  are  some  types  of  damage  for 
which  the  best  damage  control  system  is  a  well  designed  and  strong  ship.  Even  with  the  best 
flood  control  techniques,  the  USS  Princeton  would  not  have  survived  if  it  did  not  have  such  a 
strong  hull  and  good  ship  design. 

Sources:  Wikipedia.org  (http://en.wikipedia.org/wiki/USS_Princeton_%28CG- 
59%29);  Surface  Warfare  Magazine,  May/June  1999 

(http://www.navsea.navy.mil/swmagazine/summarytmp.aspx?iContentID=84&iDataPrimeID=18 
49);  Princeton’s  Mine  Encounter  (http://www.warshipsl.com/US/BB61stats/index-BB2- 
pstl7.htm).  Sources  were  last  accessed  on  28  February  2007. 

3.23.4  USS  Samuel  B.  Roberts 

On  14  April  1988,  the  USS  Samuel  B.  Roberts  was  operating  in  the  Persian  Gulf 
during  the  Iran-Iraq  war,  when  it  hit  a  mine.  The  force  of  the  blast  of  this  mine  on  the  USS 
Samuel  B.  Roberts  was  just  as  impressive  as  was  the  force  of  the  blast  on  the  USS  Princeton,  and 
just  as  devastating:  the  hull  sustained  a  15-foot  diameter  breach,  the  bow  numbers  of  the  ship 
went  almost  completely  under  water,  and  the  ship  was  essentially  cut  in  two  across  its  mid¬ 
section,  leaving  the  main  deck  as  the  essential  structural  component  holding  the  front  and  back  of 
the  ship  together.  The  Samuel  B.  Roberts  also  experienced  significant  fires  as  a  result  of  the 
blast,  with  initial  blast  fires  reaching  higher  than  the  mast  of  the  ship,  and  flames  coming  out  of 
the  intake  louvers  to  a  height  of  100  to  150  feet.  The  ship  was  at  action  stations  when  it  hit  the 
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mine,  and  it  only  sustained  ten  injuries  as  a  result.  Additionally,  all  of  the  combat  systems 
survived  the  explosion,  and  were  available  after  only  15  minutes  of  downtime  when  the  ship’s 
power  was  restored. 

The  flooding  problems  on  the  ship  were  immediately  obvious.  The  captain  brought  as 
many  pumps  as  possible  on-line,  and  was  educting  over  5000  gallons  of  water  per  minute,  but 
found  that  the  ship  was  still  sinking  at  a  rate  of  one  foot  every  fifteen  minutes.  The  flooding  was 
such  a  problem  that  at  one  point  it  was  possible  to  put  your  hands  in  the  water  from  a  kneeling 
position  at  the  stem  of  the  ship.  The  fires  were  also  a  significant  problem,  and  fighting  them  was 
adding  to  the  flooding  problem.  These  fires  were  fuelled  by  up  to  three  feet  of  fuel  resting  on  top 
of  the  water  in  the  flooded  engine  room,  so  they  had  enough  fuel  to  burn  for  a  long  time. 
Eventually,  the  commander  decided  to  stop  fighting  the  fires,  and  to  concentrate  fully  on  solving 
the  flooding  problem;  it  is  likely  that  this  is  the  decision  that  saved  the  ship.  The  ship  also  carried 
400%  of  its  allowance  of  Aqueous  Film  Forming  Foam  (AFFF),  and  used  three-quarters  of  that 
to  finally  put  out  the  fires. 

The  case  of  the  Samuel  B.  Roberts  adds  to  the  other  incidents  already  presented 
because  it  shows  how  damage  control  efforts  -  specifically  flood  control  and  fire  fighting  -  can 
be  defeated  by  one  another.  In  such  a  situation  where  a  ship  could  be  lost,  difficult  decisions 
need  to  be  made  that  few  would  want  to  trust  to  automated  systems. 

Sources:  Wikipedia.org 

(http://en.wikipedia.org/wiki/USS_Samuel_B._Roberts_%28FFG-58%29);  Surface  Warfare 
Magazine,  May/June  1999 

(http://www.navsea.navy.mil/swmagazine/summarytmp.  aspx?iContentID=84&iDataPrimeID=l  8 
49);  Surface  Warfare  Magazine,  March/ April  1990 

(http://www.dcfp.navy.mil/mc/museum/ROBERTS/Robertsl.htm).  Sources  were  last  accessed 
on  28  February  2007. 

3.23.5  USS  Stark 

On  17  May  1987,  the  USS  Stark  was  on  routine  patrol  in  the  Persian  Gulf  during 
peacetime  operations  when  it  was  hit  without  warning  by  two  Exocet  missiles  from  an  Iraqi  F-l 
Mirage  fighter.  The  first  missile  entered  the  ship  and  did  not  detonate,  but  disintegrated,  causing 
major  damage.  The  second  missile  entered  at  almost  the  same  point  as  the  first  and  exploded. 

The  impact  from  the  two  missiles  and  the  explosion  of  the  second  caused  severe  structural 
damage,  compromised  the  ship’s  watertight  integrity,  and  severed  a  fire-main.  The  combination 
of  the  explosion  from  the  second  missile  and  the  unused  propellant  from  both  missiles  caused  an 
intense  fire  that  quickly  engulfed  the  berths  where  it  hit.  37  crew  members  were  killed,  many  in 
the  berths,  and  21  were  injured. 

In  addition  to  the  damage  to  the  ship’s  structure  and  the  fires,  all  of  the  ship’s 
communications  were  lost,  and  crewmembers  had  to  communicate  with  other  ships  using  radios 
from  aircrew  survival  vests.  The  significant  number  of  casualties  meant  that  there  was  a 
tremendous  shortage  of  resources  to  use  to  combat  the  damage,  and  there  was  plenty  of  damage 
to  combat.  Fires  were  raging  where  the  missiles  hit,  and  the  ship  was  taking  on  a  significant 
amount  of  water  (both  from  hull  breaches  and  from  the  severed  fire-main)  so  that  it  eventually 
listed  to  an  angle  of  16  degrees.  The  crew  fought  the  damage  long  and  hard,  but  because  their 
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numbers  were  depleted,  were  quickly  exhausted.  The  damage  was  not  contained  until  assistance 
was  received  from  the  USS  Waddell  and  Conyngham. 


Figure  3-4.  The  USS  Stark,  severely  listing  to  port  as  a  result  of  flooding. 


Figure  3-5.  External  view  of  the  damage  caused  to  the  USS  Stark  by  two  Iraqi  Exocet  missiles. 

The  incident  on  the  USS  Stark  demonstrates  the  challenge  that  can  be  posed  when 
major  damage  is  sustained  along  with  major  casualties.  Although  the  crew  of  the  Stark  was  able 
to  perform  the  initial  response  to  its  damage,  the  long-term  solution  was  to  bring  in  resources 
from  another  ship  to  finish  the  job.  In  addition,  this  scenario  demonstrates  the  complexity 
involved  in  missile  damage.  Missiles  pose  a  triple -threat  to  ships:  their  initial  impact  can  breach 
a  ship’s  hull;  the  explosion  from  a  warhead  can  cause  severe  structural  damage  and  fires;  and 
finally,  the  unused  propellant  from  a  missile  can  cause  extremely  hot  fires  that  are  difficult  to  put 
out,  and  that  spread  quickly. 

Sources:  Wikipedia.org  (http://en.wikipedia.org/wiki/Uss_stark);  NAVSEA  DC 
Museum  (http://www.dcfp.navy.mil/mc/museum/STARK/Stark3.htm).  Sources  were  last 
accessed  on  28  February  2007. 

3.23.6  Discussion 

Overall,  these  real-life  damage  control  incidents  show  the  extreme  difficulty  posed  by 
a  major  damage  control  incident.  In  each  of  the  incidents  reviewed,  the  survivability  of  the  ship 
was  a  major  concern,  and  all  ships  could  have  been  lost  had  different  decisions  been  made.  It  is 
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also  important  to  note  that  even  though  there  are  similarities  across  these  five  incidents,  there  are 
also  perverse  differences  that  would  have  been  difficult  to  anticipate.  The  size  of  the  hull  breach 
on  the  HMS  Nottingham  was  of  a  scale  that  would  be  difficult  to  predict;  at  the  time  of  the  USS 
Cole  incident,  the  idea  of  a  marine-borne  suicide  bomb  was  novel;  the  USS  Princeton  suffered 
from  not  one,  but  two  mine  blasts;  the  damage  inflicted  on  the  USS  Samuel  B.  Roberts  resulted 
in  a  complex  interaction  between  the  two  different  damage  control  responses;  and  finally,  the 
USS  Stark  suffered  from  intense  fires  and  difficult  stability  problems.  Given  these  complexities 
and  the  very  real  risk  that  in  each  case  the  ship  would  have  been  lost,  these  incidents  define  the 
extreme  end  of  the  scale  of  damage  control  complexity. 

These  incidents  also  provide  a  commentary  on  the  challenges  faced  by  advanced 
automation  in  the  face  of  complex  damage  control  incidents.  Each  of  the  incidents  discussed 
involved  novel  approaches  to  damage  control  tailored  to  the  individual  circumstances  at  hand; 
just  as  it  would  be  difficult  to  predict  the  particular  circumstances  encountered  in  the  design  of 
an  automated  solution,  it  would  also  be  difficult  to  design  automated  solutions  to  address  much 
of  the  damage. 

Finally,  these  incidents  emphasize  that  converting  the  constraint-based  representation 
of  the  work  domain  in  the  AH  model  into  a  display  for  shipboard  damage  control  could  have 
helped  crews  to  manage  some  of  the  complex  interactions  at  play  in  these  scenarios.  For 
example,  if  ships  had  an  accurate  way  to  gather  information  about  the  constraints  of  the  Stability 
functional  purpose,  it  could  be  clear  when  efforts  to  fight  fires  were  also  sinking  the  ship. 

3.2.4  Review  of  DC-ARM  Scenarios 

Researchers  in  the  DC-ARM  project  created  peacetime  and  wartime  scenarios  for 
testing  the  advanced  automation  for  damage  control  they  developed.  Two  different  types  of 
scenarios  were  developed  to  test  the  advanced  automation  from  two  perspectives  -  the  peacetime 
scenarios  were  designed  to  investigate  the  effects  of  the  advanced  automation  on  the  situation 
awareness  of  the  Damage  Control  Officer,  and  the  wartime  scenarios  were  designed  to 
investigate  the  capability  of  the  automation  to  contain  damage  to  what  is  called  the  Primary 
Damage  Area,  or  the  area  initially  affected  by  the  damage  incident.  Both  types  of  scenarios  are 
mises  en  scene. 

These  two  types  of  scenarios  are  described  below. 

3.2.4.1  Peacetime  Scenarios 

The  peacetime  scenarios  seem  to  have  been  designed  to  include  incidents  that  might 
confuse  the  DC-ARM  early-warning  fire  detection  system.  For  example,  the  incidents  included 
trash  can  fires,  smouldering  electric  cables,  and  smouldering  bedding  as  incidents  that  the 
automation  should  classify  as  fires,  and  toasting  Pop-Tarts,  diesel  engine  exhaust,  and  welding  as 
incidents  the  automation  should  not  classify  as  fires.  These  scenarios  were  designed  to  be 
conducted  in  situations  similar  to  Peacetime  Cruising  under  Damage  Control  Condition  ‘Y’  on 
the  Halifax  class  frigate. 

3.2.4.2  Wartime  Scenarios 

The  wartime  scenarios  were  designed  to  simulate  the  effects  of  being  hit  by  a  medium 
anti-ship  missile,  and  involved  assumptions  about  the  bulkheads  that  would  be  ruptured,  the  fires 
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and  floods  that  would  be  caused,  and  the  number  of  casualties  that  would  occur.  The  types  of 
damage  that  are  specified  are  quite  specific  to  characteristics  of  the  ex-USS  Shadwell  as  a 
damage  simulator  (for  example,  the  use  of  a  large  heptane  spray  fire  combined  with  a  wood  crib 
fire  in  the  Communications  Centre  /  Crew  Living  Space).  These  scenarios  were  designed  to  be 
conducted  in  conditions  similar  to  Action  Stations  under  Damage  Condition  ‘Z’  on  the  Halifax 
class  frigate. 

3.2.4.3  Discussion 

Especially  the  peacetime  DC-ARM  scenarios  are  relevant  from  the  point  of  view  of 
testing  automation,  as  they  deal  specifically  with  the  potential  for  false  positive  or  false  negative 
alarms,  and  concerns  related  to  inappropriate  trust  in  automation  (Section  1.3. 4. 4).  Depending  on 
the  types  of  sensors  chosen  during  Phase  III  of  this  project,  it  may  be  useful  to  test  the  robustness 
of  human-machine  system  in  the  face  of  such  nuisance  incidents.  The  wartime  scenarios  also 
involve  the  interesting  automation  challenge  that  actual  operational  priorities  need  be  considered 
instead  of  just  saving  the  ship. 

3.3  SCENARIO  DEVELOPMENT 

3.3.1  Overview 

This  section  presents  the  medium-  and  high-complexity  scenarios  that  were 

developed. 

3.3.2  Complexity  definition 

To  develop  medium  and  high  complexity  damage  scenarios,  it  was  important  to  first 
define  ‘complexity’  with  respect  to  a  damage  scenario.  In  other  words,  what  is  the  baseline  level 
of  complexity  for  a  medium  complexity  damage  scenario,  and  what  is  the  difference  between  a 
medium-complexity  scenario  and  a  high-complexity  scenario?  When  damage  control  SMEs  were 
consulted  for  their  views  on  these  topics,  their  opinion  was  that  complexity  is  best  measured  by 
the  amount  of  damage  control  work  induced  by  the  scenario,  that  a  medium  complexity  scenario 
should  be  challenging  but  routine,  and  that  a  high  complexity  scenario  should  be  difficult,  and 
close  to  the  limit  of  what  a  crew  should  be  expected  to  cope  with.  Since  this  definition  of 
complexity  and  the  interpretations  of  medium  and  high  complexity  resounded  well  with  the 
SMEs  being  consulted,  they  were  used  as  the  basis  for  the  initial  development  of  the  damage 
scenarios. 


While  these  ideas  were  useful  for  brainstorming  about  scenarios  with  damage  control 
SMEs,  as  the  scenarios  were  refined,  so  too  these  ideas  needed  refinement.  Especially  this  initial 
definition  of  complexity  had  a  significant  problem  in  the  context  of  this  project:  it  is  a  process 
definition  (that  is,  it  is  about  how  things  get  done)  and  as  such,  it  defines  complexity  in  an  actor- 
dependent  way.  While  the  scenarios  that  were  generated  may  be  complex  given  the  current 
configuration  of  the  Halifax  class  frigate,  if  the  same  process  definition  of  complexity  were 
applied  to  those  scenarios  in  the  context  of  a  different  damage  control  system  and  crewing  level 
in  the  Halifax  class  frigate,  it  is  possible  that  the  scenarios  would  not  be  at  all  complex,  or  that 
they  would  be  prohibitively  complex.  To  continue  with  the  strong  actor-independent  flavour  of 
this  research,  it  was  important  to  replace  this  process-oriented  definition  of  complexity  with  a 
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product  definition,  that  is,  a  definition  either  about  what  is  damaged  or  about  what  actor- 
independent  processes  need  to  be  invoked  to  control  the  damage. 

The  project  team  was  able  to  identify  two  different  candidate  measures  of  complexity: 

a.  Scales  of  incident.  Brooks  and  Bailer  (2006)  have  proposed  a  measure  of  incident 
criticality  for  scenario  development  called  ‘Scales  of  incident’  that  is  actor 
independent.  It  is  based  on  the  type  of  event,  the  time  required  to  contain  the 
damage,  the  effect  on  ship  systems,  and  the  expected  type  of  resolution.  While  the 
precise  details  of  this  measure  cannot  be  included  in  this  report  (the  original 
report  was  provided  to  the  project  team  under  restrictions),  it  is  still  possible  to 
evaluate  the  proposed  scenarios  against  this  measure  and  report  the  degree  to 
which  this  measure  indicates  that  the  scenarios  differ  in  their  complexity. 

b.  AH  coverage.  The  AH  produced  in  the  first  phase  of  this  project  is  also  a  useful 
tool  for  assessing  the  complexity  of  the  scenarios.  Under  the  assumption  that  a 
scenario  that  involves  a  large  number  of  the  constraints  in  the  AH  is  more 
complex  than  one  that  involves  only  a  small  number  of  constraints,  a  method  was 
developed  for  assessing  AH  coverage.  This  method  involves  assessing  the 
scenario  against  each  level  of  the  AH,  as  follows: 

■  Physical  Form,  Physical  Function  and  Generalized  Function  levels.  For 

these  levels,  for  each  AH  node,  the  number  of  sections  or  tanks  of  the  ship  in 
which  the  constraints  of  the  AH  node  are  broken  or  threatened  are  counted 
(where  a  section  is  any  space  on  any  deck  bounded  fore  and  aft  by  a 
watertight  bulkhead4). 

■  Abstract  Function  and  Functional  Purpose  levels.  For  these  levels,  the 
number  of  AH  nodes  whose  constraints  are  threatened  or  broken  by  the 
damage  are  counted.  In  addition,  if  a  constraint  is  threatened,  the  severity  of 
the  threat  to  or  breakage  of  the  constraint  is  classified  as  high  or  low. 5 

Comparing  these  counts  at  each  level  across  scenarios  should  at  least  corroborate 
the  results  of  the  scales  of  incident  measure  (above). 


4  The  AH  Physical  Form  level  treated  the  ship  from  the  point  of  view  of  compartments,  but  for  the  purposes  of  this 
measure  of  complexity,  a  count  of  individual  compartments  is  not  diagnostic  of  the  extent  of  damage  present.  While 
sections  themselves  vary  in  size,  the  number  of  compartments  within  a  section  varies  much  more.  If  individual 
compartments  were  counted,  damage  that  occurred  in  a  section  of  the  ship  with  many  compartments  would  appear 
more  severe  than  damage  that  appeared  in  another  section  of  the  ship  with  fewer  compartments.  Of  course,  even 
counting  sections  is  not  a  fully  valid  measure  of  complexity,  but  it  should  be  adequate  for  the  purposes  of  this 
project. 

5  An  alternate  approach  could  have  been  to  base  the  differences  in  counting  technique  on  the  levels  of 
decomposition,  and  so  counting  items  at  the  system  and  subsystem  levels  of  decomposition  (the  Functional  Purpose, 
Abstract  Function,  and  Generalized  Function  levels  of  abstraction)  using  the  method  described  above  for  the  abstract 
function  and  functional  purpose  levels,  and  items  at  the  component  level  of  decomposition  (the  Physical  Function 
and  Physical  Form  levels  of  abstraction)  using  the  method  described  above  for  the  Physical  Form,  Physical 
Function,  and  Generalized  Function  levels  of  abstraction.  While  there  is  merit  in  this  approach,  the  only  method  the 
project  team  found  for  evaluating  severity  at  that  Generalized  Function  level  was  by  counting  and  comparing  the 
number  of  sections  affected,  the  approach  that  was  finally  followed. 
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The  results  of  applying  these  measures  to  the  medium  and  high  complexity  scenarios 
are  presented  in  Section  3.3.6,  below. 

3.3.3  Stopping  rules 

In  addition  to  characterizing  scenario  complexity,  it  was  also  necessary  to  determine 
the  scenario  stopping  rules,  the  criteria  that  must  be  met  for  the  damage  incurred  by  a  scenario  to 
be  considered  resolved  or  out  of  control.  These  criteria  are  as  follows: 

a.  Resolved  damage.  The  criteria  for  damage  resolution  differ  for  the  three  main 
types  of  damage.  Fire  damage  is  considered  to  be  resolved  when  all  fires  have 
been  extinguished  and  the  risk  of  re-ignition  has  been  eliminated.6  Flood  damage 
is  considered  to  be  resolved  when  either  the  ship  is  not  taking  on  any  additional 
water  or  when  the  net  amount  of  inflow  to  the  ship  is  equal  to  or  less  than  the  net 
amount  of  outflow.  Structural  damage  is  considered  to  be  resolved  once  any 
shoring  required  to  prevent  the  spread  of  the  structural  damage  has  been  put  into 
place.  Note  that  these  resolution  criteria  were  determined  based  on  the  traditional 
responsibilities  of  a  ship’s  damage  control  organization,  and  are  all  met  prior  to 
any  repair  that  might  be  performed  by  CSEs  or  at  a  dockyard. 

b.  Out-of-control  damage.  The  criteria  to  determine  if  damage  is  out-of-control 
also  differ  for  the  three  main  types  of  damage.  Fires  are  considered  to  be  out-of¬ 
control  if  they  propagate  past  the  secondary  propagation  zones;  floods  are 
considered  to  be  out  of  control  if  the  ship  is  sunk;  and  structural  damage  is 
considered  to  be  out  of  control  if  the  ship  no  longer  has  structural  integrity  (i.e.,  it 
breaks  into  two  or  more  pieces).  No  damage  control  system  can  be  considered 
capable  if  it  allows  any  of  these  criteria  to  be  met.7 

These  stopping  rules  helped  to  determine  the  extent  to  which  the  damage  control 
scenarios  were  expanded,  and  also  were  the  basis  for  some  of  the  MOEs  presented  in  Section 
3.5. 

3.3.4  Medium  complexity  damage  scenario 

3.3.4. 1  Overview 

The  medium  complexity  damage  scenario  that  was  developed  is  presented  in  Figure 
3-6.  This  scenario  is  based  on  the  typical  damage  problems  that  crews  would  face  midway 
through  ship  WUPS,  and  involves  non-critical  flooding  in  a  number  of  tanks  and  the  Command 
and  Control  Equipment  Room  #4  (CCER  4),  a  potentially  large  fire  in  the  Galley,  and  a 
secondary  fire  in  the  Refrigeration  Machinery  Space  (RMS). 


6  On  the  Halifax  class  frigate,  reducing  the  risk  of  re-ignition  is  done  by  a  process  called  ‘overhauling’.  For  class  A 
fires  this  involves  searching  every  compartment  affected  by  fire  to  verify  that  no  smouldering  materials  remain;  for 
class  B  fires  it  involves  spraying  a  layer  of  AFFF  in  compartment  affected  by  fire;  and  for  class  C  fires  it  involves 
isolating  the  power  supply  to  the  equipment  on  fire.  Currently  this  is  a  conservative  procedure  (e.g.,  for  class  A  fires 
every  locker  and  drawer  is  emptied  and  wet  down). 

7  The  criteria  for  determining  if  flooding  and  structural  integrity  problems  are  out  of  control  may  be  weak.  The 
work-domain  constraints  related  to  these  criteria  were  not  taxed  in  either  of  the  scenarios  that  were  developed  and  so 
these  criteria  were  not  analyzed  as  rigorously  as  the  criterion  for  fire. 
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33.4.2  Initial  conditions 

The  initial  conditions  for  this  scenario  are  a  ship  involved  in  peacetime  cruising,  in 
Damage  condition  ‘Y\  The  condition  of  peacetime  cruising  means  that  crew  would  not  be  at 
actions  stations,  but  rather  would  be  serving  their  regular  watches.  Damage  condition  ‘Y’  means 
that  all  doors  and  hatches  below  the  waterline  separating  watertight  compartments  from  one 
another  (called  ‘Y’  openings)  would  be  closed. 

An  unfortunate  implication  of  this  choice  is  that  peacetime  cruising  implies  that  ships 
have  a  ‘safe-at-sea’  priority.  This  means  that  in  the  event  of  damage,  the  damage  control  priority 
is  not  to  maintain  some  mission  capability,  but  rather  to  keep  the  ship  and  her  crew  as  safe  as 
possible.  As  a  result,  there  will  be  much  less  difficulty  in  managing  the  damage  control  response 
because  one  set  of  constraints  (those  of  the  Functional  Purpose  of  Mission  Effectiveness)  are  out 
of  play.  If  possible,  it  would  be  beneficial  to  design  the  simulator  to  be  developed  after  Phase  III 
of  this  project  to  be  able  to  run  scenarios  under  different  initial  conditions  so  that  both  peacetime 
and  wartime  contexts  could  be  tested. 

It  should  also  be  noted  that  not  having  the  crew  at  action  stations  biases  these 
scenarios  in  favour  of  automated  damage  control  systems.  Automated  systems  do  not  suffer  from 
fatigue  in  the  same  way  as  humans,  and  so  can  always  be  at  an  enhanced  level  of  readiness  to 
combat  damage.  Fortunately,  even  though  this  bias  exists,  it  is  realistic.  Ships  do  not  typically 
keep  their  crew  at  action  stations  because  it  cannot  be  sustained  for  long  periods  of  time,  and  is 
typically  unnecessary. 

3.3.43  Framing  story 

The  framing  story  for  the  medium  complexity  damage  scenario  is  as  follows:  while 
sailing  on  a  foggy  day,  the  ship  hits  an  ISO  container0  that  has  fallen  from  a  container  ship  and  is 
floating  free  in  the  ocean.  The  impact  causes  a  gash  across  a  number  of  the  ship’s  tanks  and  a 
puncture  in  the  hull  at  the  CCER  4.  The  shock  from  the  impact  induces  fires  in  both  the  Galley 
and  the  RMS. 

This  framing  story  for  this  scenario  will  likely  resonate  with  naval  SMEs.  There  are 
many  floating  hazards  in  the  ocean,  and  hitting  a  large  one  could  cause  significant  damage. 

33.4.4  Notable  features 

Under  the  current  Halifax  class  frigate  damage  control  system,  this  is  a  relatively 
straightforward  damage  scenario.  It  poses  two  interesting  challenges  that  will  be  useful  test-cases 
for  more  modern  damage  control  systems: 

a.  Two  fires  in  close  proximity  to  one  another.  The  fires  in  the  Galley  and  the 
RMS  are  in  close  proximity  to  one  another.  Since  there  are  typically  personnel  in 
the  Galley,  the  alarms  indicating  a  fire  in  the  Galley  would  quickly  be 
corroborated  by  an  eyewitness  account.  The  RMS,  on  the  other  hand,  is  not  a 
manned  space.  Since  it  is  so  close  to  the  galley,  it  is  possible  that  any  smoke 
alarms  from  that  space  would  be  considered  as  a  secondary  indication  of  the 


8  Readers  unfamiliar  with  ISO  containers  can  refer  to  the  Wikipedia  article  on  container  shipping 
(http  ://en.  wikipedia.  org/wiki/Containerization) . 
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galley  fire  (due  to  smoke  spread)  and  not  a  primary  indicator  of  a  different  fire  in 
this  space.  It  is  expected  that  advanced  automation  will  ensure  that  the  presence  of 
two  separate  fires  will  be  diagnosed  more  quickly  than  with  the  current  system. 

b.  Toxic  fumes.  Toxic  fumes  may  be  released  as  a  result  of  the  fire  in  the  RMS.  This 
would  be  a  consideration  in  providing  any  manned  response  to  the  fire  in  this 
space. 

c.  Access  and  planning.  Since  it  is  likely  that  with  the  current  Halifax  class  frigate 
damage  control  system  the  initial  diagnosis  of  the  damage  situation  would  be  a 
single  fire  in  the  Galley,  this  fire  would  likely  be  assigned  to  the  FSB.  On 
attacking  the  Galley  fire,  the  FSB  team  would  feel  that  the  floor  under  their  feet 
was  heating  up,  and  a  communication  loop  would  have  to  be  engaged  to  re-plan 
the  fire  boundaries  and  to  allow  the  FSB  to  attack  the  fire  in  the  RMS.  While  the 
FSB  is  attacking  the  fire  in  the  RMS,  HQ1  would  have  to  task  another  attack  team 
to  attack  the  galley  fire  (this  team  could  come  from  the  FSB,  ASB,  or  the 
manning  pool).  Again,  it  is  likely  that  the  effects  of  this  complication  would  be 
mitigated  by  advanced  automation. 

The  flooding  concerns  involved  in  this  scenario  are  not  significant,  and  the  flooding 
here  is  more  of  a  nuisance  than  a  threat.  However,  with  different  initial  conditions  (e.g.,  wartime) 
the  effect  of  this  flooding  could  be  quite  significant,  as  the  Command  and  Control  Equipment 
Room  includes  much  of  the  primary  command  and  control  data  processing  equipment. 
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Medium  Complexity  Damage  Scenario 

Initial  Ship  Condition:  Peacetime  Cruising  -  Damage  Control  Condition  Y 


While  sailing  on  a  foggy  day,  the  ship  collides  with  an  ISO  Container  (see  image,  right)  that  has  fallen  off  of  a  container  ship.  The  container 
impacts  the  ship  on  the  starboard  bow,  causing  a  gash  that  runs  from  the  Salt  Water  Ballast  /  Standby  Diesel  Fuel  Oil  tank  #1  (6B)  to  the 
Diesel  Fuel  Oil  Tank  #1  (6C)  and  an  additional  large  hole  below  the  waterline  in  the  Command  and  Control  Equipment  Room  (4CZ).  The  shock 
from  the  impact  induces  a  fire  in  the  Galley  (3EZ1)  and  the  Refrigeration  Machinery  Space  (4DZ0). 


Figure  3-6.  Medium  complexity  damage  scenario  showing  initial  conditions,  framing  story,  and  damage  propagation 
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Figure  3-7.  An  exploded  view  of  the  Halifax  class  frigate  showing  the  initial  damage  and  primary  and  secondary  propagations  for  the  medium  complexity 

damage  scenario 
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3.3.5  High  complexity  damage  scenario 

3.3.5. 1  Overview 

The  high  complexity  damage  scenario  that  was  developed  is  presented  in  Figure  3-8. 
This  scenario  is  reminiscent  of  the  most  difficult  damage  scenarios  that  Sea  Training  presents  to 
crews  close  to  the  end  of  ship  WUPS.  It  involves  a  large  explosion  in  the  aft  of  the  ship  that 
inflicts  heavy  casualties  in  nearby  messes  (about  30  junior  engineering  staff)  and  induces  a  large 
multi-zone  fire.  A  few  minutes  later,  this  initial  damage  is  added  to  by  a  collision  with  a  fishing 
boat  that  causes  moderate  flooding  and  two  additional  fires  amidships.  The  casualties  inflicted  by 
the  initial  explosion  induce  a  severe  manning  shortage  for  damage  control,  because  the  messes 
affected  by  the  explosion  house  many  of  the  ranks  that  normally  make  up  the  damage  control 
attack  teams.  Further,  the  explosion  also  incapacitates  the  ASB;  even  if  the  ASB  would  be  able 
to  relocate,  it  would  be  without  its  fire-fighting  gear. 

3.3.5.2  Initial  conditions 

The  initial  conditions  for  the  high  complexity  scenario  are  the  same  as  those  for  the 
medium  complexity  scenario,  and  involve  the  same  benefits  and  drawbacks.  The  reader  is 
referred  to  Section  3. 3. 4. 2  for  more  details. 

3.3.5.3  Framing  story 

The  framing  story  for  the  high  complexity  damage  scenario  is  as  follows:  While  on  a 
fisheries  patrol,  the  oxygen  and  acetylene  tanks  in  the  Shipwright’s  Workshop  explode,  causing 
devastating  damage  in  sections  2L  and  3L,  a  great  deal  of  damage  in  the  surrounding  sections, 
and  heavy  casualties  (about  30  junior  engineering  staff)  in  the  messes  in  section  3L.  The 
explosion  also  severs  the  ship’s  steering  cables,  causing  a  loss  of  ship’s  steering,  and  severs  a 
fire-main,  causing  flooding  until  the  break  can  be  addressed. 

With  the  ship’s  steering  disabled,  four  minutes  later  it  is  unable  to  avoid  a  collision 
with  a  steel-hulled  fishing  boat.  This  collision  occurs  amidships,  in  the  area  of  the  Forward 
Auxiliary  Machinery  Room  (FAMR),  and  causes  flooding  in  FAMR  and  fires  in  the  Forward 
Switchboard  and  the  Forward  A/C  Plant. 

While  the  framing  story  for  this  scenario  is  somewhat  contrived,  the  types  of  damage 
incurred  are  representative  of  some  of  the  actual  damage  control  incidents  reviewed  in  Section 
3.2.3.  The  USS  Stark  sustained  damage  in  the  area  of  its  crew  messes,  and  37  crewmembers 
were  lost,  and  the  USS  Cole  sustained  damage  in  the  area  of  its  engineering  spaces  (similar  to  the 
FAMR)  which  caused  major  flooding  of  the  same.  While  the  combination  of  these  two  types  of 
damage  may  be  unlikely,  difficult  damage  control  cases  are  often  difficult  precisely  because  they 
are  unexpected. 

3.3.5.4  Notable  features 

Under  the  current  Halifax  class  frigate  damage  control  system,  this  is  a  very  complex 
damage  scenario.  There  are  many  challenges  and  features  of  this  scenario  that  would  be  useful 
test-cases  for  more  modern  damage  control  systems: 
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a.  Stress  and  uncertainty.  The  initial  explosion  would  likely  cause  a  great  deal  of 
stress  for  those  responsible  for  coordinating  the  damage  control  effort,  and  the 
extent  of  the  damage  (and  the  casualties)  would  likely  be  difficult  to  ascertain 
quickly  with  current  systems.  This  would  make  planning  difficult,  and  increases 
the  likelihood  that  crews  will  fixate  on  certain  courses  of  action  too  early.  This 
feature  represents  an  opportunity  for  advanced  automation,  but  in  combination 
with  (c),  below,  also  represents  a  challenge.  Poorly  designed  automation, 
especially  clumsy  automation,  could  exacerbate  this  situation. 

b.  Resource  shortages  and  decision  making.  Since  the  explosion  at  the  beginning 
of  the  scenario  inflicts  casualties  on  so  many  of  the  crew,  and  since  these  crew 
(junior  engineering  staff)  are  typically  relied  upon  for  the  manned  part  of  a 
damage  control  response,  even  with  reliable  information  about  the  extent  of  the 
casualties,  it  will  be  a  challenge  to  deploy  personnel  effectively  to  control  the 
damage  in  the  most  efficient  way.  Since  great  flexibility  and  intuitive  decision 
making  (Klein,  1998)  are  likely  to  be  great  assets  in  confronting  these  resource 
shortages  -  especially  in  the  context  of  incomplete  or  uncertain  information  -  this 
feature  will  likely  be  better  handled  by  manned  rather  than  automated  solutions  to 
damage  control. 

c.  System  failures.  It  is  likely  that  a  large  explosion  would  cause  any  elements  of  a 
damage  control  system  that  were  distributed  across  a  ship  (e.g.,  sensors  and 
actuators)  to  fail.  Recommendations  from  an  automated  system  could  be  based  on 
incomplete  information,  and  operators  may  be  prone  to  trust  these 
recommendations  inappropriately.  In  addition,  any  fitted  fire  systems  would  likely 
be  compromised.  Again,  this  feature  favours  a  manned  solution  to  damage 
control. 

d.  Potential  for  fire  spread.  Resource  shortages  will  increase  the  amount  of  time 
required  to  muster  a  manned  response  to  any  of  the  damage,  and  so  the  likelihood 
that  the  damage  will  spread  increases.  This  feature  favours  an  automated  system 
that  could  quickly  address  the  fires  resulting  from  the  collision  with  the  fishing 
boat,  so  that  resources  could  be  freed  to  deal  with  the  larger  fires  to  the  aft  of  the 
ship  before  they  spread. 

Under  a  set  of  initial  conditions  that  would  place  the  ship  in  a  conflict,  features  (a) 
and  (b)  would  be  exacerbated  as  the  task  of  damage  control  coordination  would  also  involve 
managing  the  ship’s  current  priorities  to  keep  all  critical  ship  systems  up  and  running.  This  is  an 
especially  important  consideration  with  the  fire  in  the  Forward  Switchboard.  Under  peacetime 
operations,  shutting  down  this  switchboard  to  allow  for  fire-fighting  would  be  a  quick  and  easy 
decision,  but  during  a  conflict,  this  switchboard  would  likely  not  be  shut  down  as  easily. 


3.21 

©  2007  CMC  Electronics,  Inc. 


31  March  2007 


CMC  ELECTRONICS  INC. 

HUMAN  FACTORS  ENGINEERING 


DOC  NO 
1000-1370-2 


High  Complexity  Damage  Scenario 

Initial  Ship  Condition:  Peacetime  Cruising  -  Damage  Control  Condition  Y 


During  a  routine  fisheries  patrol,  there  is  an  explosion  of  the  oxygen  and  acetylene  tanks  in  the  Shipwright’s  Workshop  (2LZ4).  The  explosion 
devastates  the  area  from  the  NBC  Filter  Compartment  #4  (2MA2),  most  of  zone  2L,  much  of  zone  2K  (including  the  Small  Arms  Magazine 
[2KZ2],  A/C  Plant  #1  [2KB2],  and  the  Sonar  Instrument  Space  #1  [2KZ0]),  and  zone  3L  (a  mess  deck,  where  heavy  casualties  are  inflicted  on 
the  junior  staff).  In  addition,  the  explosion  ruptures  the  fire  main  running  through  2L,  and  the  steering  power  cables  are  severed  causing  a 

loss  of  steering. 

With  its  steering  disabled,  four  minutes  after  the  explosion  the  ship  is  struck  by  a  steel-hulled  fishing  boat  in  the  area  of  the  Forward  Auxiliary 
Machinery  Room.  The  impact  causes  the  ship’s  plates  to  buckle  at  the  waterline,  which  induces  flooding  in  the  FAMR.  In  addition,  the  shock 

induces  fires  in  the  A 1C  Plant  #2  (3EA2)  and  the  Switchboard  #1  (2EZ2). 
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Figure  3-8.  High  complexity  damage  scenario  showing  initial  conditions,  framing  story,  and  damage  propagation 
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Figure  3-9.  An  exploded  view  of  the  Halifax  class  frigate  showing  the  initial  damage  and  primary  and  secondary  propagations  for  the  high  complexity 

damage  scenario 
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3.3.6  Analysis  of  scenario  complexity 

The  complexity  of  the  medium  and  high  complexity  scenarios  was  analysed  based  on 
the  measures  of  complexity  presented  in  Section  3.3.2.  The  results  of  this  analysis  are  presented 
below. 

3.3.6.1  Scales  of  incident 

Using  the  scales  of  incident  measure  (Brooks  &  Bailer,  2006),  the  medium 
complexity  can  be  characterized  as  a  single  significant  incident  from  which  a  frigate  should  be 
able  to  easily  recover.  The  high  complexity  incident  involves  one  critical  incident  coupled  with  a 
significant  incident.  In  terms  of  ship  recoverability,  the  results  of  this  measure  indicate  that  a 
frigate  the  size  of  the  Halifax  class  frigate  should  easily  be  able  to  recover  from  the  medium- 
complexity  scenario,  and  that  the  high  complexity  scenario  is  within,  but  at  the  edge  of,  the 
boundary  of  the  damage  the  Halifax  class  frigate  should  be  able  to  recover  from.  This  result  is  a 
clear  indication  that  there  is  an  important  difference  in  the  complexity  of  the  two  scenarios,  with 
the  high  complexity  scenario  being  more  complex.  In  addition,  the  basic  level  of  complexity  of 
both  scenarios  is  reasonable  and  useful  for  further  phases  of  this  project. 

3.3.6.2  AH  coverage 

The  result  of  applying  the  AH  coverage  measure  of  complexity  to  the  scenarios  is 
shown  in  Table  3-1,  below. 

Table  3-1.  Results  of  applying  the  AH  coverage  measure  of  complexity  to  the  medium  and  high 
complexity  damage  scenarios 


AH  Coverage 

Level  of  Abstraction 

Medium  Complexity 

High  Complexity 

High  severity  -  0 

High  severity  -  3: 

■  Manoeuvrability 

■  Mission  effectiveness 

■  Personnel  safety 

■ 

Functional  Purpose 

Low  severity  -  6: 

■  Stability 

■  Manoeuvrability 

■  Mission  effectiveness 

■  Personnel  safety 

■  Economic  stewardship 

■  Environmental  protection 

Low  severity  -  3: 

■  Stability 

■  Economic  stewardship 

■  Environmental  protection 

Abstract  Function 

High  severity  -  0 

High  severity  -  4: 

■  Reserve  buoyancy 

■  Structural  integrity 

■  Ability  to  maintain  desired  course 

■  Minimize  casualties 

Low  severity  -11: 

Low  severity  -  8: 
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■  Reserve  buoyancy 

■  Structural  integrity 

■  Positive  righting  arm 

■  List  and  trim 

■  Ability  to  maintain  operational 
speed 

■  Ability  to  navigate 

■  Ability  to  sense  environment 

■  Ability  to  affect  environment 

■  Minimize  casualties 

■  Minimize  resource  damages 

■  Minimize  environmental  impact 

■  Positive  righting  arm 

■  List  and  trim 

■  Ability  to  communicate 

■  Ability  to  navigate 

■  Ability  to  sense  environment 

■  Minimize  resource  damages 

■  Minimize  environmental  impact 

Generalized  Function 

AH  nodes  x  sections  affected  - 
18: 

■  Freeboard  -  1 

■  Watertight  integrity  -  3 

■  Load  and  balance  -  3 

■  External  communications  -  3 

■  Power  generation  &  distribution  - 
1 

■  Targeting  sensors  -  1 

■  Effectors  -  1 

■  Protective  measures  -  2 

■  Prompt  response  -  2 

■  Spill  prevention  /  containment  -  1 

AH  nodes  x  sections  affected  -  24: 

■  Freeboard  -  1 

■  Watertight  integrity  -  1 

■  Structural  strength  -  2 

■  Load  and  balance  -  2 

■  Propulsion  -  1 

■  Power  generation  &  distribution  - 
1 

■  Helicopter  support  -  1 

■  Protective  measures  -  6 

■  Prompt  response  -  6 

■  Prevention  measures  -  1 

■  Spill  prevention  /  containment  -  1 

■  Responsible  resource  allocation  - 
1 

AH  nodes  x  sections  affected  - 

AH  nodes  x  sections  affected  -  23: 

10: 

■  Flood  control  -  2 

■  Flood  control  -  3 

■  Fire  suppression  -  6 

Physical  Function 

■  Fire  suppression  -  2 

■  Fire  containment  -  6 

■  Fire  containment  -  2 

■  Ventilation  -  6 

■  Ventilation  -  2 

■  Power  isolation  -  1 

■  Power  isolation  -  3 

Physical  Form 

AH  nodes  x  sections  affected  -  5 

AH  nodes  x  sections  affected  -  7 

The  differences  in  the  severity  of  damage  can  be  seen  in  a  number  of  comparisons  up 
the  AH.  First,  even  though  the  amount  of  damage  at  the  Physical  Form  level  is  similar  for  the 
medium  and  high  complexity  scenarios  (5  versus  7  nodes  x  sections  affected),  the  small 
difference  is  magnified  up  the  levels  of  abstraction.  At  the  Physical  Function  level,  there  is  a 
difference  of  13  nodes  x  sections  affected;  and  at  the  Generalized  Function  level,  there  is  a 
difference  of  6  nodes  x  sections  affected.  Even  though  the  scope  of  threatened  or  broken 
constraints  at  the  Abstract  Function  and  Functional  Purpose  levels  of  abstraction  are  similar,  the 
medium  complexity  scenario  has  no  threatened  or  broken  constraints  of  high  severity,  while  for 
the  high  complexity  scenario,  7  of  18  of  the  threatened  or  broken  constraints  are  high  severity. 

These  results  show  that  there  is  an  important  difference  in  the  levels  of  complexity  of 
the  two  scenarios,  with  the  high  complexity  scenario  being  more  complex. 
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3.4  TASK  INVENTORIES 

The  task  inventory  that  was  developed  is  shown  in  the  table  below.  In  general,  the 
individual  items  are  self-explanatory;  where  some  amplification  is  useful,  a  note  has  been  added 
to  the  item  in  italics.  Note  that  the  numbering  of  these  items  is  meant  to  imply  a  plausible 
ordering.  If  the  dynamics  of  a  real  damage  control  situation  were  to  be  observed,  many  loops  and 
shunts  would  certainly  be  observed,  some  tasks  would  be  performed  in  parallel,  and  others  might 
be  performed  in  a  very  different  order  than  presented  here. 

Table  3-2.  Task  inventory  for  the  medium  and  high  complexity  damage  scenarios. 


1  Monitor  ship  state.  A  high-level  control  function  that  includes  all  of  the  ship  properties  that  need  to 
be  monitored  to  detect  damage  and  control  it  effectively. 

1 .1  Monitor  ship  spaces9 

1.1.1  Monitor  ship  spaces  for  presence  of  fire 

1 .1 .2  Monitor  ship  spaces  for  presence  of  smoke 

1.1.3  Monitor  ship  spaces  for  presence  of  water  /  floods 

1 .2  Monitor  ship  structure 

1 .2.1  Monitor  hull  for  breaches 

1 .2.2  Monitor  decks  and  bulkheads  for  structural  integrity 

1 .3  Monitor  ship  ventilation 

1 .3.1  Monitor  state  of  ventilation  system 

1 .3.2  Monitor  state  of  hatches  and  doors 

1 .3.3  Monitor  state  of  ventilation  valves 

1.4  Monitor  ship  load  and  balance 

1 .4.1  Monitor  ship's  reserve  buoyancy 

1.4.2  Monitor  ship's  list  and  trim 

1 .4.3  Monitor  ship's  righting  arm 

1.5  Monitor  ship  mission  requirements 

1.5.1  Monitor  command  priorities 

1 .5.2  Monitor  current  damage  control  state 

1.6  Monitor  ship  personnel 

1 .6.1  Monitor  location  of  ship  personnel 

1 .6.2  Monitor  health  of  ship  personnel 

1 .7  Monitor  state  of  ship  systems.  The  damage  control  effort  can  be  helped  by  information  about 
the  state  of  all  systems  that  could  cause,  exacerbate,  or  prevent  a  damage  control  event  (e.g.,  if 
the  anti-missile  defence  systems  are  not  functioning  while  the  ship  is  in  an  area  with  missile 
threats,  this  knowledge  can  assist  damage  control  in  predicting  the  types  of  damage  that  could 
occur). 

1 .8  Monitor  state  of  damage  control  systems 


9  Although  the  Halifax  class  frigate  currently  includes  heat  sensors,  the  detection  of  heat  is  only  a  means  to  the 
detection  of  fire. 
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2  Coordinate  damage  control  response.  A  high-level  control  function  concerned  with  detecting 

damage  (if  any),  assessing  its  impact,  and  addressing  that  damage  in  the  most  efficient  way  given  the 
ship’s  current  priorities  and  resource  constraints. 

2.1  Detect  damage 

2.1.1  Detect  fire 

2. 1.1.1  Detect  fire  location 

2. 1.1. 2  Detect  fire  type 

2.1 .1 .3  Detect  fire  intensity 

2.1.2  Detect  flood 

2.1 .2.1  Detect  flood  location 

2.1 .2.2  Detect  flood  source 

2. 1.2. 3  Detect  flood  volume 

2.1 .2.4  Detect  flood  rate 

2.1 .3  Detect  structural  problems 

2. 1.3.1  Detect  hull  breaches 

2. 1.3. 2  Detect  bulkhead  and  wall  problems 

2.1 .4  Detect  load  and  balance  problems 

2.2  Assess  impact  of  damage 

2.2.1  Assess  impact  of  detected  fire 

2. 2. 1.1  Assess  impact  of  fire  on  ship's  functional  purposes 

2.2.1 .2  Assess  impact  of  fire  on  accessibility  to  ship  spaces  and  equipment. 

2.2.1 .3  Assess  potential  for  fire  to  spread  to  adjacent  spaces 

2.2.1 .4  Assess  impact  of  fire  spread  to  adjacent  spaces  using  criteria  in  2.2.1 .1  -  2.2.1 .3 

2.2.2  Assess  impact  of  detected  flood 

2.2.2. 1  Assess  impact  of  flood  on  ship's  functional  purposes 

2.2.22  Assess  impact  of  flood  on  accessibility  to  ship  spaces  and  equipment 

2. 2. 2. 3  Assess  potential  for  free  surface  effect  problems  to  arise 

2. 2. 2.4  Assess  potential  for  free  communication  effect  problems  to  arise 

2. 2. 2. 5  Assess  potential  for  flood  to  spread  to  adjacent  spaces 

2. 2. 2. 6  Assess  impact  of  flood  spread  to  adjacent  spaces  using  criteria  in  2.2.2. 1  -  2. 2. 2. 5 

2.2.3  Assess  impact  of  detected  structural  problems 

2.2.3. 1  Assess  impact  of  structural  problems  on  ship's  functional  purposes 

2. 2. 3. 2  Assess  impact  of  structural  problems  on  accessibility  to  ship  spaces  and  equipment 

2. 2. 3. 3  Assess  potential  for  structural  problems  to  compound 

2. 2. 3.4  Assess  impact  of  problem  compounding  using  criteria  in  2.2.3. 1  -  2. 2. 3.4 

2.2.4  Assess  impact  of  detected  load  and  balance  problems 

2.2.4. 1  Assess  impact  of  load  and  balance  problems  on  ship's  functional  purposes 

2. 2. 4. 2  Assess  impact  of  load  and  balance  problems  on  accessibility  to  ship  spaces  and 
equipment 

2. 2. 4. 3  Assess  potential  for  load  and  balance  problems  to  compound 

2. 2. 4.4  Assess  impact  of  problem  compounding  using  criteria  in  2.2.4. 1  -  2. 2.4.4 

2.3  Determine  resource  constraints 
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2.4  Determine  damage  control  strategy 

2.5  Allocate  (or  re-allocate)  resources  to  resolve  damage 

2.6  Resolve  damage 

3  Control  fire.  A  high-level  control  function  concerned  with  controlling  fire  damage  based  on  the 
damage  control  response  maintained  by  function  2.  Note  that  smoke  clearance  is  not  included  in  this 
task,  as  it  is  a  concern  that  typically  falls  outside  of  the  purview  of  damage  control. 

3.1  Contain  fire 

3.1 .1  Shut  down  ventilation  system  to  affected  section 

3.1 .2  Close  bulkhead  isolation  valves 

3.1 .3  Close  all  relevant  doors  and  hatches 

3.2  Bound  fire 

3.2.1  Set  and  maintain  boundary  above  fire  (if  possible) 

3.2.2  Set  and  maintain  boundary  aft  of  fire  (if  possible) 

3.2.3  Set  and  maintain  boundary  forward  of  fire  (if  possible) 

3.2.4  Set  and  maintain  boundary  below  fire  (if  possible) 

3.2.5  Set  and  maintain  boundary  port  of  fire  (if  possible) 

3.2.6  Set  and  maintain  boundary  starboard  of  fire  (if  possible) 

3.3  Prepare  to  control  fire 

3.3.1  Choose  strategy  to  control  fire 

3.3.2  Ensure  availability  of  fire  control  resources 

3.3.3  Coordinate  personnel  safety  for  chosen  strategy.  If  a  fire  is  to  be  fought  by  humans,  this 
would  include  power  isolation. 

3.4  Extinguish  fire 

3.5  Confirm  fire  extinguished 

4  Control  flood.  A  high-level  control  function  concerned  with  controlling  flood  damage  based  on  the 
damage  control  response  maintained  by  function  2. 

4.1  Contain  flood 

4.1 .1  Close  all  relevant  doors  and  hatches 

4.1 .2  Close  all  relevant  ventilation  valves  (M  openings,  on  vertical  ventilation  trunking) 

4.1 .3  Shore  up  bulkheads,  decks,  and  hatches  as  necessary 

4.2  Remove  /  manage  source  of  flood 

4.3  Remove  flood  water 

4.3.1 .1  Remove  water  from  affected  space  to  bilge 

4.3.1 .2  Remove  water  from  affected  space  to  sea 

4.4  Remove  bilge  water 

4.4. 1.1  Separate  oils  from  water 

4.4. 1 .2  Remove  water  from  bilge  to  sea 

5  Control  structural  problems.  A  high-level  control  function  concerned  with  controlling  structural 
damage  based  on  the  damage  control  response  maintained  by  function  2. 

5.1  Shore  up  bulkheads,  decks,  and  hatches  as  necessary 

6  Control  load  and  balance  problems.  A  high-level  control  function  concerned  with  controlling  load 
and  balance  problems  based  on  the  damage  control  response  maintained  by  function  2. 

6.1  Redistribute  loads  across  the  ship 
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6.1.1  Drain  water  to  lower  decks 

6.1 .2  Move  equipment,  supplies,  and  fittings 

6.1 .3  Transfer  equipment,  supplies,  and  fittings  to  another  platform 

6.1 .4  Jettison  equipment,  supplies,  and  fittings 
6.2  Remove  bilge  water 

6.2.1  Separate  oils  from  water 

6.2.2  Void  water  from  bilge  to  sea 


In  the  process  of  cross-checking  the  full  concerns  of  each  of  these  tasks  against  the 
AH  of  damage  control,  the  project  team  discovered  that  in  its  treatment  of  the  Generalized 
Function  of  Load  and  Balance,  the  existing  AH  does  not  include  concerns  related  to  ice 
accumulation  on  the  superstructure  of  the  ship.  While  ice  accumulation  is  not  a  damage  control 
concern,  current  levels  of  ice  accumulation  or  the  potential  for  ice  accumulation  to  arise  could  be 
an  important  input  to  the  overall  load  and  balance  of  the  ship.  No  other  items  of  concern  were 
identified. 

3.5  MEASURES  OF  EFFECTIVENESS 

The  MOEs  that  were  developed  are  presented  in  Table  3-3,  below.  This  table  presents 
the  MOEs  organized  by  node  of  the  AH  to  which  they  are  related.  Many  of  the  MOEs  also 
correspond  to  specific  tasks  from  the  task  inventory;  where  this  is  the  case,  the  reference  to  the 
task  inventory  item  is  included  in  brackets.10 

For  many  of  the  AH  nodes  at  the  Functional  Purpose  and  Abstract  Function  levels  of 
abstraction,  there  are  no  specific  MOEs.  This  is  because  the  concepts  at  these  levels  are  at  such  a 
high  level  that  no  single  measure  expresses  them  adequately;  rather,  MOEs  for  these  nodes  are 
best  expressed  as  an  aggregate  of  the  MOEs  identified  for  the  nodes  they  are  connected  to  by 
‘means’  (downwards)  links. 

In  addition,  specific  target  levels  for  each  of  the  MOEs  have  not  been  established.  It 
is  expected  that  the  good  performance  on  most  of  the  MOEs  will  be  represented  by  simple 
minimum  or  maximum  functions,  or  integrations  of  these  functions  over  time.  For  example,  all 
other  things  being  equal,  a  damage  control  system  that  can  ensure  a  positive  righting  arm  and 
maximize  the  righting  arm  over  time  is  to  be  preferred.  Again,  all  other  things  being  equal,  a 
damage  control  system  that  can  ensure  a  minimum  amount  of  list  and  trim  over  time  is  to  be 
preferred. 


Finally,  although  it  is  likely  that  some  MOEs  are  more  important  than  others,  they 
have  not  been  prioritized.  For  example,  the  US  Naval  Research  Lab  is  currently  placing  a  high 
priority  on  developing  damage  control  systems  that  will  extinguish  fires  before  they  spread, 
which  implies  that  the  MOE  Number  of  compartments  affected  by  fire  spread  may  have  a  higher 


10  All  of  the  tasks  in  the  task  inventory,  with  the  exception  of  all  tasks  under  1  Monitor  Ship  State  and  the 
management  tasks  under  2  Coordinate  damage  control  response  (specifically,  2.3  Determine  resource 
constraints,  2.4  Determine  damage  control  strategy,  and  2.5  Allocate  (or  re-allocate)  resources  to  resolve 
damage)  were  converted  into  MOEs. 
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priority  in  the  selection  of  an  acceptable  damage  control  system  than  the  MOE  Time  to  assess 
impact  of  fire. 

Table  3-3.  Measures  of  effectiveness. 


AH  Node 

MOE 

Functional  Purpose 

1.01 

Stability 

Ability  for  personnel  to  stay  on  ship 

Period  of  ship  roll 

1.02 

Manoeuvrability 

Ability  to  move  under  own  power 

1.03 

Mission  effectiveness 

Ability  to  remain  on  station 

1.04 

Personnel  safety 

Number  of  casualties 

1.05 

Economic  stewardship 

Overall  monetary  impact  of  damage 

1.06 

Environmental  protection 

Impact  of  ship  on  environment  (potentially  qualitative) 

Abstract  Function 

2.01 

Reserve  Buoyancy 

Volume  of  the  watertight  portion  of  the  ship  above  the  waterline 

2.02 

Structural  integrity 

Amount  of  designed  structural  integrity  remaining 

2.03 

Positive  righting  arm 

Righting  arm 

Righting  moment 

2.04 

List  and  trim 

Amount  of  list 

Amount  of  trim 

2.05 

Ability  to  maintain 
operational  speed 

Difference  between  maximum  speed  possible  and  operational 
speed 

2.06 

Ability  to  maintain  desired 
course 

Available  turning  rate 

Available  turning  radius 

2.07 

Ability  to  communicate 

Time  required  to  communicate  and  receive  feedback  on  an 
internal  message 

Time  required  to  communicate  and  receive  feedback  on  an 
external  message 

2.08 

Ability  to  navigate 

Time  required  to  obtain  current  position 

Accuracy  of  position  reckoning 

2.09  Ability  to  sense  Range  of  available  sensors 

environment  Time  required  to  obtain  position,  course,  and  speed  for  a  contact 


Accuracy  of  position,  course,  and  speed  reckoning 
Accuracy  of  friend/foe  determination 


2.10 

Ability  to  affect 
environment 

Range  of  required  effectors 

Capability  of  required  effectors 

2.11 

Minimize  casualties 

Number  of  casualties 

2.12 

Minimize  resource 
damages 

Monetary  value  of  damaged  resources 

2.13 

Minimize  resource 
expenditures 

Monetary  value  of  resources  expended 

2.14 

Minimize  environmental 
impact 

Impact  of  ship  on  environment  (potentially  qualitative) 

Generalized  Function 
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AH  Node 

MOE 

3.01 

Freeboard 

Distance  between  waterline  and  the  top  of  the  watertight  structure 
of  the  ship 

3.02 

Watertight  integrity 

Total  influx  of  water 

Amount  of  shoring  or  repairs  in  use  to  maintain  watertight  integrity 

3.03 

Structural  strength 

Safety  margin  afforded  by  overall  remaining  structural  strength 

3.04 

Load  and  balance 

Weight/volume  of  water  taken  on  by  flooding 

Time  to  detect  load  and  balance  problems  (Task  2.1.4) 

Accuracy  of  detection  of  load  and  balance  problems  (Task  2.1.4) 
Time  to  assess  impact  of  load  and  balance  problems  (Task  2.2.4) 
Accuracy  of  assessment  of  impact  of  load  and  balance  problems 
(Task  2.2.4) 

Time  to  redistribute  loads  across  the  ship  (Task  6.1) 

Time  to  remove  bilge  water  (Task  6.2) 


3.05 

Propulsion 

Number  of  propulsion  sources  available 

Amount  of  time  each  propulsion  source  is  unavailable  due  to  the 
effects  of  damage 

3.06 

Steering 

Availability  of  steering  systems 

Amount  of  time  steering  systems  are  unavailable 

3.07 

Internal  comms 

Availability  of  internal  communications  systems 

Amount  of  time  internal  communications  systems  are  unavailable 

3.08 

External  comms 

Availability  of  external  communications  systems 

Amount  of  time  external  communications  systems  are  unavailable 

3.09 

Navigation  sensors 

Availability  of  navigation  sensors 

Amount  of  time  navigation  sensors  are  unavailable 

3.10 

Power  generation  and 
distribution 

Amount  of  power  available 

Integrity  of  power  network 

3.11 

Targeting  sensors 

Availability  of  targeting  sensors 

Amount  of  time  targeting  sensors  are  unavailable 

3.12 

Effectors 

Availability  of  effectors 

Amount  of  time  effectors  are  unavailable 

3.13 

Flelicopter  support 

Availability  of  helicopter  support 

Amount  of  time  helicopter  support  is  unavailable 

3.14 

Protective  measures 

(None) 

3.15 

Prompt  response 

Total  time  from  onset  of  damage  to  containment 

3.16 

Prevention  measures 

(None) 

3.17 

Spill  prevention  / 
containment 

Volume  of  bilge-water  expelled  from  ship 

3.18 

Resource  allocation 

(None) 

Physical  Function 
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AH  Node  MOE 

4.01  Flood  control  Time  to  detect  flood  (Task  2.1 .2) 

Accuracy  of  flood  detection  (Task  2.1.2) 

Time  to  assess  impact  of  flood  (Task  2.2.2) 

Accuracy  of  assessed  impact  of  floods  (Task  2.2.2) 

Time  to  contain  flood  (Task  4.1) 

Time  to  remove  /  manage  source  of  flood  (Task  4.2) 

Time  to  remove  flood  water  (Task  4.3) 

Number  of  compartments  lost  to  sea  due  to  primary  damage 
Number  of  compartments  lost  to  sea  outside  of  primary  damage 
zone  (or,  secondary  flooding) 

4.02  Structural  reinforcement  Time  to  detect  structural  problems  (Task  2.1.3) 

Accuracy  of  structural  problem  detection  (Task  2.1 .3) 

Time  to  assess  impact  of  structural  problems  (Task  2.2.3) 
Accuracy  of  assessed  impact  of  structural  problems  (Task  2.2.3) 
Time  to  enact  shoring  (Task  5.1 ) 


4.03  Fire  suppression  Time  to  detect  fire  (Task  2.1 .1 ) 

Accuracy  of  fire  detection  (Task  2.1.1) 

Time  to  assess  impact  of  fire  (Task  2.2.1) 
Accuracy  of  assessed  impact  of  fire  (Task  2.2.1) 
Number  of  compartments  affected  by  fire  spread1 
Energy  release  rate  for  fi re+ 

Time  to  prepare  to  control  fire  (Task  3.3) 

Time  to  extinguish  fire  (Task  3.4) 

Time  to  confirm  fire  extinguished  (Task  3.5) 


4.04  Fire  containment  First  six  MOEs  from  Fire  Suppression  plus.. . 


Time  to  contain  fire  (Task  3.1 ) 
Time  to  bound  fire  (Task  3.2) 


4.05 

Ventilation 

Time  to  shut  down  ventilation  to  affected  section  (Task  3.1.1) 
Number  of  compartments  (besides  those  with  fire)  affected  by 
smoke 

4.06 

Power  isolation 

Time  to  isolate  power  for  personnel  safety  (Task  3.3.3) 

Number  of  ship  systems  affected  by  power  isolation 

j. 

Measures  sourced  from  Williams,  et  al.  (2003). 
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SECTION  FOUR:  DISCUSSION,  CONCLUSIONS,  AND 
RECOMMENDATIONS 


4.1  GENERAL 

This  section  provides  some  final  conclusions  of  the  scenario  development  effort  and 
recommendations  for  Phase  111  of  this  project  as  well  as  the  follow-on  simulation  effort. 

4.2  DISCUSSION  -  THE  CONTINUING  USEFULNESS  OF  THE  AH 

While  much  of  the  discussion  of  the  results  of  this  project  has  already  occurred  in  the 
presentation  of  the  results,  there  is  one  notable  result  which  still  requires  a  brief  discussion. 
Throughout  the  conduct  of  this  work,  the  project  team  was  pleasantly  surprised  at  ongoing 
usefulness  of  the  AH  representation  of  damage  control  developed  in  Phase  I  of  this  project.  In 
Phase  I,  the  development  of  that  model  was  critical  to  gaining  the  in-depth  knowledge  of  damage 
control  required  to  be  able  to  develop,  document,  and  substantiate  the  scenarios  presented  in  this 
report.  In  this  phase  of  the  project,  the  AH  model  was  a  useful  touchstone  at  many  points  along 
the  way.  The  rigour  with  which  a  work-domain  analysis  enforces  an  actor-independent  view  of  a 
work-domain  was  instrumental  in  developing  the  methodology  followed  in  this  work  (see,  for 
example,  the  discussion  on  the  nature  of  scenarios  at  Section  1.3.2  or  the  discussion  on  damage 
propagation  in  Section  1.3.3).  The  AH  also  paid  back  dividends  in  the  development  of  MOEs. 
First,  the  idea  that  the  project  is  still  at  an  actor-independent  stage  helped  in  clarifying  that  only 
MOEs  (and  not  MOPs)  are  germane  at  this  phase  of  analysis,  and  second,  the  AH  provided  a 
useful  structure  for  generating  a  comprehensive  set  of  MOPs. 

4.3  CONCLUSIONS 

This  report  has  presented  the  development  of  a  medium  complexity  and  a  high 
complexity  scenario  for  damage  control.  These  scenarios  are  based  on  insights  from  current  CF 
naval  damage  control  training  scenarios,  research  on  recent  real-world  damage  control  incidents, 
interviews  with  naval  damage  control  SMEs,  and  an  understanding  of  the  human  performance 
issues  introduced  by  advanced  automation.  Consideration  has  been  made  to  ensure  that  these 
scenarios  will  be  useful  in  the  context  of  the  simulation  effort  for  which  this  work  is  laying  a 
foundation,  especially  in  that  these  scenarios  have  been  developed  to  be  actor-independent,  and 
so  should  readily  generalize  across  any  combinations  of  damage  control  equipment  and  crewing 
that  could  be  installed  in  (a  simulation  of)  the  Halifax  class  frigate.  These  scenarios  have  been 
analysed  against  two  different  measures  of  damage  control  complexity  to  demonstrate  that  their 
levels  of  complexity  are  useful  and  sufficiently  different  from  one  another.  Finally,  an  actor- 
independent  task  inventory  of  all  of  the  work  required  to  combat  the  damage  of  these  scenarios, 
as  well  as  MOEs  to  compare  different  evolutions  of  damage  control  work  have  been  provided. 
All  of  which  is  to  say,  the  project  team  is  confident  that  the  methodology  and  results  presented  in 
this  volume  meet  the  objectives  for  which  they  were  requested,  and  are  a  good  basis  for  the 
future  phases  of  work. 

4.4  RECOMMENDATIONS 

The  following  recommendations  arise  from  the  work  presented  in  this  volume: 
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a.  Recommend  continuing  with  Phase  III  of  this  project.  The  work  on  Phases  I 
and  II  of  this  project  have  been  productive  and  successful,  and  the  project  team  is 
confident  that  the  work  completed  to  date  is  a  strong  basis  for  the  final  phase  of 
this  project. 

b.  Recommend  researching  potential  damage  control  simulators.  The  results 
presented  in  Section  1.3.3  argue  strongly  that  this  project  would  be  well-served  by 
adopting  some  existing  damage  control  simulator  instead  of  building  one  from 
scratch.  A  proposed  first  step  in  this  research  would  be  to  conduct  a  visit  with  Dr. 
Fred  Williams  of  the  NRL  to  discuss  his  experiences  with  such  simulators. 

c.  Recommend  researching  the  application  of  Ecological  Interface  Design  to 
damage  control.  Seeing  that  the  AH  of  damage  control  has  been  so  useful  in  this 
project  to  date,  it  would  be  useful  to  investigate  if  the  AH  would  also  translate 
well  into  an  interface  designed  according  to  the  principles  of  Ecological  Interface 
Design  (Burns  &  Hajdukiewicz,  2004;  Vicente  &  Rasmussen,  1992).  This  would 
also  be  helpful  in  understanding  how  the  concept  of  object  worlds  developed  in 
Phase  I  of  this  project  can  extend  from  analysis  into  design. 

d.  Investigate  ways  to  enable  a  simulation  to  run  under  both  peacetime  and 
wartime  conditions.  The  decision  to  base  both  of  the  scenarios  in  this  volume  on 
peacetime  cruising  conditions  has  limitations;  to  mitigate  those  limitations,  it 
would  be  useful  if  the  simulation  that  is  hoped  to  be  a  follow-on  to  this  work  will 
be  flexible  enough  to  allow  for  peacetime  and  wartime  conditions  (and  the 
different  mission  priorities  introduced  by  the  latter). 

e.  Investigate  ways  to  add  automation  complications  to  the  simulation  of  the 
scenarios.  Table  1-1  in  Section  1.3.4. 8  summarizes  the  implications  of  the 
various  characteristics  of  human  performance  with  advanced  automation  on  the 
development  of  automation  for  damage  control.  These  implications  should  be 
reviewed  prior  to  developing  a  simulator  to  investigate  ways  in  which  the 
simulator  could  be  made  flexible  enough  to  include  these  conditions  in  sensitivity 
analyses. 

f.  Promote  the  scenarios  developed  in  this  phase  of  the  project,  as  well  as  the 
rationale  behind  them,  to  developers  and/or  vendors  of  damage  control 
systems.  It  is  possible  that  the  scenarios  developed  in  this  phase  of  the  project  and 
their  rationale  would  be  of  benefit  for  Canadian  industry.  If  there  are  any 
possibilities  to  promote  this  report  to  Canadian  industry  as  a  starting  point  for 
including  automation  considerations  in  scenario  development,  these  should  be 
pursued. 
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ANNEX  A:  GLOSSARY  OF  TERMS  AND  ACRONYMS 


AFFF 

AH 

ASB 

Aqueous  Film  Forming  Foam 

Abstraction  Hierarchy 

Aft  Section  Base 

CCER  4 

Cdr 

CF 

CFB 

CFNES 

CPO 

CSE 

Command  and  Control  Equipment  Room  #4 
Commander 

Canadian  Forces 

Canadian  Forces  Base 

Canadian  Forces  Naval  Engineering  School 

Chief  Petty  Officer 

Combat  Systems  Engineering 

DC-ARM 

DCTF 

DRDC-T 

Damage  Control  Automation  for  Reduced  Manning 
Damage  Control  Training  Facility 

Defence  Research  and  Development  Canada  -  Toronto 

ERT 

Emergency  Response  Team 

FAMR 

FSB 

FSSIM 

Forward  Auxiliary  Machinery  Room 

Forward  Section  Base 

Fire  and  Smoke  Simulator 

HF 

HFE 

HQ1 

Human  Factors 

Human  Factors  Engineering 

Damage  Control  Headquarters 

LCdr 

Lieutenant  Commander 

MOD 

MOE 

MOP 

MSE 

Ministry  of  Defence 

Measure  of  Effectiveness 

Measure  of  Performance 

Maritime  Systems  Engineering 

NRL 

(US  Navy)  Naval  Research  Lab 

RMS 

Refrigeration  Machinery  Space 

SA 

SB3 

SCSC 

SME 

Scientific  Authority 

Section  Base  3 

Single-Class  Surface  Combatant 

Subject  Matter  Expert 

WUPS 

Workups 
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ANNEX  B:  AGENDA  FOR  SME  DATA  COLLECTION  MEETING 

Reproduced  below  is  the  agenda  for  the  SME  meeting  that  was  held  on  November  2, 
2006,  for  the  purpose  of  developing  the  initial  ideas  for  the  scenarios  for  this  project. 


Scenario  Development  to  Support  a  Simulation  of  Shipboard  Damage  Control 

SME  Data  Collection 

Held  at  Sea  Training,  Halifax,  November  2,  2006 
PROVISIONAL  AGENDA 

1.  Welcome  (8:00 -8:15) 

2 .  Rules  of  Engagement  (8:15-8:30) 

3.  Introduction  (8:30-9:15) 

a.  Project  Overview 

b.  Data  Collection  Objectives 

c.  Scenario  Requirements 

i.  Complexity 

ii.  Scope 

iii.  Other  characteristics 

d.  Measures  of  Effectiveness  /  Performance 

4.  Scenario  Identification  (9:15-10:15) 

5.  Break  (10:15- 10:30) 

6.  Develop  Medium  Complexity  Scenario  (10:30  -  12:00) 

7.  Lunch  (12:00-  13:00) 

8.  Develop  High  Complexity  Scenario  (13:00  -  14:30) 

9.  Break  (14:30-  14:45) 

10.  Revisit  /  Refine  Scenarios  (14:45  -  15:45) 

11.  Wrap-up  &  Adjournment  (15:45  -  16:00) 
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